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ABSTRACT 


High-resolution  combat  simulations  that  model  urban  combat  currently  use 
computationally  expensive  algorithms  to  represent  urban  target  acquisition  at  the  entity 
level.  While  this  may  be  suitable  for  small-scale  urban  combat  scenarios,  simulation  run 
time  can  become  unacceptably  long  for  larger  scenarios.  Consequently,  there  is  a  need 
for  models  that  can  lend  insight  into  target  acquisition  in  urban  terrain  for  large-scale 
scenarios  in  an  acceptable  length  of  time. 

This  research  develops  urban  target  acquisition  models  that  can  be  substituted  for 
existing  physics-based  or  computationally  expensive  combat  simulation  algorithms  and 
result  in  faster  simulation  run  time  with  an  acceptable  loss  of  aggregate  simulation 
accuracy.  Specifically,  this  research  explores  (1)  the  adaptability  of  probability  of  line  of 
sight  estimates  to  urban  terrain;  (2)  how  cumulative  distribution  functions  can  be  used  to 
model  the  outcomes  when  a  set  of  sensors  is  employed  against  a  set  of  targets;  (3)  the 
uses  for  Markov  Chains  and  Event  Graphs  to  model  the  transition  of  a  target  among 
acquisition  states;  and  (4)  how  a  system  of  differential  equations  may  be  used  to  model 
the  aggregate  flow  of  targets  from  one  acquisition  state  to  another. 
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EXECUTIVE  SUMMARY 


Emerging  Army  organization  and  operational  coneepts  are  leading  the  movement 
toward  a  lighter,  more  agile  foree  -  a  foree  that  is  inereasingly  dependent  upon  multi¬ 
sensor  collection  of  information  across  the  battlespace.  As  a  result,  today’s  Army  has 
become  more  reliant  upon  information  dominance  in  order  to  achieve  its  objectives.  A 
large  component  of  information  dominance  on  the  modem  battlefield  lies  in  the  field  of 
urban  target  acquisition.  The  outcomes  of  current  and  future  military  operations  will  be 
highly  correlated  with  urban  target  acquisition  capabilities.  Thus,  in  order  to  model 
modem  combat  effectively,  current  combat  simulations  must  accurately  represent  target 
acquisition  in  urban  terrain.  While  urban  target  acquisition  may  be  a  simple  concept  to 
understand,  it  is  certainly  a  complicated  concept  to  model. 

Currently,  high-resolution  combat  simulations  that  model  urban  combat  use 
computationally  expensive  algorithms  to  model  urban  target  acquisition  at  the  entity 
level.  While  this  may  be  suitable  for  small-scale  urban  combat  scenarios,  simulation  mn 
time  can  become  unacceptably  long  for  large-scale  urban  combat  scenarios. 
Consequently,  there  is  a  need  for  models  that  can  lend  insight  into  target  acquisition  in 
urban  terrain  for  large-scale  scenarios  in  an  acceptable  length  of  time.  Such  models 
could  be  used  to  improve  simulation  run  time  or  be  employed  where  aggregate  target 
acquisition  models  were  previously  non-existent. 

The  objective  of  this  research  is  to  develop  urban  target  acquisition  models  that 
can  be  substituted  for  existing  physics-based  or  computationally  expensive  combat 
simulation  algorithms  and  result  in  faster  simulation  run  time  with  an  acceptable  loss  of 
aggregate  simulation  accuracy.  Our  approach  to  accomplishing  this  objective  is  to  apply 
mathematical  modeling  tools  in  novel  ways  to  represent  urban  target  acquisition.  Our 
focus  is  not  to  develop  these  models  to  completion;  rather,  it  is  our  intent  to  demonstrate 
the  utility  of  our  approach  and  methodology  in  order  to  direct  future  research  efforts. 

Our  research  concentrates  on  two  distinct  areas:  (1)  adapting  probability  of  line 
of  sight  estimates  to  urban  terrain  and  (2)  developing  stochastic  and  analytical  models 
that  can  lend  insight  into  urban  target  acquisition. 

xvii 


First,  we  investigate  the  adaptability  of  probability  of  line  of  sight  estimates  to 
urban  terrain.  This  is  done  through  the  development  of  a  prototype  simulation  that 
estimates  probabilities  of  line  of  sight  in  urban  terrain  for  a  given  urban  terrain  type, 
sensor  elevation,  and  sensor-to-target  range.  Furthermore,  we  demonstrate  the  usefulness 
of  this  simulation  through  the  generation  of  urban  probability  of  line  of  sight  eurves. 
Additionally,  we  present  some  emerging  topies  unique  to  urban  probability  of  line  of 
sight  to  whieh  further  researeh  should  be  dedieated. 

Seeond,  we  examine  stoehastic  and  analytical  models  that  may  lend  insight  into 
target  acquisition  in  urban  terrain.  Specifically,  we  explore  how  (1)  cumulative 
distribution  functions  can  be  used  to  model  the  outcomes  when  a  set  of  sensors  is 
employed  against  a  set  of  targets;  (2)  Markov  Chains  and  Event  Graphs  can  be  used  to 
model  the  transition  of  a  target  among  acquisition  states;  and  (3)  a  system  of  differential 
equations  may  be  used  to  model  the  aggregate  flow  of  targets  from  one  state  to  another. 
Our  intent  is  to  determine  which  of  these  proposed  models  shows  promise  in  developing 
faster  simulation  algorithms.  For  those  models  that  do  show  promise,  we  develop  them 
further  and  explain  their  utility  in  a  combat  simulation  that  models  large-scale  urban 
combat  scenarios. 


I.  INTRODUCTION 


A.  OVERVIEW 

Emerging  Army  organization  and  operational  concepts  are  leading  the  movement 
toward  a  lighter,  more  agile  force  -  a  force  that  is  increasingly  dependent  upon  multi¬ 
sensor  collection  of  information  across  the  battlespace.  As  a  result,  today’s  Army  has 
become  more  reliant  upon  information  dominance  in  order  to  achieve  its  objectives.  A 
large  component  of  information  dominance  on  the  modem  battlefield  lies  in  the  field  of 
urban  target  acquisition.  The  outcomes  of  current  and  future  military  operations  will  be 
highly  correlated  with  urban  target  acquisition  capabilities.  Thus,  in  order  to  model 
modem  combat  effectively,  current  combat  simulations  must  accurately  represent  target 
acquisition  in  urban  terrain.  While  urban  target  acquisition  may  be  a  simple  concept  to 
understand,  it  is  certainly  a  complicated  concept  to  model. 

Currently,  high-resolution  combat  simulations  that  model  urban  combat  use 
computationally  expensive  algorithms  to  model  urban  target  acquisition  at  the  entity 
level.  While  this  may  be  suitable  for  small-scale  urban  combat  scenarios,  simulation  mn 
time  can  become  unacceptably  long  for  large-scale  urban  combat  scenarios. 
Consequently,  there  is  a  need  for  models  that  can  lend  insight  into  target  acquisition  in 
urban  terrain  for  large-scale  scenarios  in  an  acceptable  length  of  time.  Such  models 
could  be  used  to  improve  simulation  run  time  or  be  employed  where  aggregate  target 
acquisition  models  were  previously  non-existent. 

B.  THESIS  OBJECTIVES 

The  objective  of  this  research  is  to  develop  urban  target  acquisition  models  that 
can  be  substituted  for  existing  physics-based  or  computationally  expensive  combat 
simulation  algorithms  and  result  in  faster  simulation  run  time  with  an  acceptable  loss  of 
aggregate  simulation  accuracy.  Our  approach  to  accomplishing  this  objective  is  to  apply 
mathematical  modeling  tools  in  novel  ways  to  represent  urban  target  acquisition.  Our 
focus  is  not  to  develop  these  models  to  completion;  rather,  it  is  our  intent  to  demonstrate 
the  utility  of  our  approach  and  methodology  in  order  to  direct  future  research  efforts. 
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C.  THESIS  SCOPE 

Our  research  concentrates  on  two  distinct  areas:  (1)  adapting  probability  of  line 
of  sight  estimates  to  urban  terrain  and  (2)  developing  stochastic  and  analytical  models 
that  can  lend  insight  into  urban  target  acquisition. 

First,  we  investigate  the  adaptability  of  probability  of  line  of  sight  estimates  to 
urban  terrain.  This  is  done  through  the  development  of  a  prototype  simulation  that 
estimates  probabilities  of  line  of  sight  in  urban  terrain  for  a  given  urban  terrain  type, 
sensor  elevation,  and  sensor-to-target  range.  Furthermore,  we  demonstrate  the  usefulness 
of  this  simulation  through  the  generation  of  urban  probability  of  line  of  sight  curves. 
Additionally,  we  present  some  emerging  topics  unique  to  urban  probability  of  line  of 
sight  to  which  further  research  should  be  dedicated. 

Second,  we  examine  stochastic  and  analytical  models  that  may  lend  insight  into 
target  acquisition  in  urban  terrain.  Specifically,  we  explore  how  (1)  cumulative 
distribution  functions  can  be  used  to  model  the  outcomes  when  a  set  of  sensors  is 
employed  against  a  set  of  targets;  (2)  Markov  Chains  and  Event  Graphs  can  be  used  to 
model  the  transition  of  a  target  among  acquisition  states;  and  (3)  a  system  of  differential 
equations  may  be  used  to  model  the  aggregate  flow  of  targets  from  one  state  to  another. 
Our  intent  is  to  determine  which  of  these  proposed  models  shows  promise  in  developing 
faster  simulation  algorithms.  For  those  models  that  do  show  promise,  we  develop  them 
further  and  explain  their  utility  in  a  combat  simulation  that  models  large-scale  urban 
combat  scenarios. 

D,  THESIS  SPONSORS 

This  research  is  funded  by  the  Army  Model  and  Simulation  Office  (AMSO)  and 
is  further  sponsored  by  the  Urban  Operations  Focus  Area  Collaborative  Team  (UO 
FACT)  and  the  Army’s  Training  and  Doctrine  Command  Analysis  Center,  Monterey 
(TRAC-MTRY). 
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II. 


PROBABILITY  OF  LINE  OF  SIGHT  IN  URBAN  TERRAIN 


A.  BACKGROUND 

In  order  for  a  combat  simulation  to  model  modern  combat  accurately,  it  must 
incorporate  methods  to  evaluate  whether  or  not  one  entity  detects  another  entity  on  the 
battlefield.  While  detection  is  certainly  a  simple  concept  to  understand,  it  is  not  always  a 
simple  concept  to  model.  Detection  is  dependent  upon  numerous  factors;  one  of  these 
factors  is  line  of  sight  (LOS). 

The  LOS  factor  is  simply  a  yes  or  no  answer:  does  one  entity  have  LOS  to 
another  entity?  Various  algorithms  exist  for  computing  LOS  in  open  terrain;  the  most 
widely  used  open  terrain  LOS  algorithms  are  discussed  in  (Champion,  1995)  and 
(Champion,  2002).  While  these  algorithms  have  subtle  differences,  almost  all  open 
terrain  LOS  algorithms  use  a  common  basis  to  determine  whether  a  sensor  has  LOS  to  a 
target:  comparison  of  slopes.  First,  using  given  elevation  data,  the  slope  of  the  line 
connecting  the  sensor  to  the  target  is  computed.  Next,  for  sufficiently  many  intermediate 
points  on  the  ground  directly  between  the  sensor  and  the  target,  the  slope  of  the  line 
connecting  the  sensor  to  the  intermediate  point  is  computed  (this  process  of  computing 
“intermediate”  slopes  is  usually  accomplished  by  successively  “stepping”  along  the 
underlying  terrain  skin  from  the  sensor  location  to  the  target  location).  If  any  of  these 
intermediate  slopes  exceeds  the  slope  from  the  sensor  to  the  target,  then  the  sensor  does 
not  have  LOS  to  the  target.  Figure  1  shows  a  simplified  illustration  of  LOS 
determination  in  open  terrain. 
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Computing  LOS  in  urban  terrain  is  even  more  complieated,  as  man-made 
structures,  such  as  buildings,  can  block  LOS.  Additionally,  targets  might  be  located 
inside  man-made  structures,  effectively  blocking  LOS  from  any  location.  Thus,  an 
algorithm  to  compute  LOS  in  urban  terrain  must  evaluate  whether  LOS  is  blocked  by  the 
underlying  terrain  skin  and,  at  a  minimum,  man-made  structures  (more  sophisticated 
algorithms  would  consider  vegetation,  obscurants,  etc.).  Figure  2  demonstrates  the 
complexities  introduced  to  LOS  by  man-made  structures  in  urban  terrain. 
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Figure  2.  Complexities  Introduced  to  LOS  by  Urban  Terrain 


1,  Probability  of  Line  of  Sight 

As  one  can  imagine,  LOS  algorithms  can  become  quite  complex  in  combat 
simulations.  Combine  this  with  the  fact  that,  by  nature,  LOS  calculations  must  be 
frequently  executed,  and  one  can  understand  why  LOS  algorithms  can  consume  a  large 
amount  of  computing  time  in  a  combat  simulation.  As  a  result,  researchers  have  focused 
a  large  amount  of  effort  to  find  more  efficient  or  equally  useful  methods  for  computing 
LOS.  One  of  these  approaches  is  to  use  probability  of  line  of  sight  (PLOS)  in  place  of 
traditional  LOS  calculations. 

PLOS  calculations  use  digital  elevation  data  to  estimate  the  probability  that  LOS 
exists  at  a  given  sensor- to-target  range  (this  is  ground  range,  not  slant  range;  see  Figure 
3),  sensor  elevation,  and  terrain  type.  A  combat  simulation  using  a  PLOS  methodology 
would  calculate  PLOS  estimates  for  each  sensor-to-target  range,  sensor  elevation,  and 
terrain  type  in  pre-processing  (prior  to  the  actual  simulation  run)  and  store  them  in  a 
PLOS  “look-up  table.”  Then,  when  the  simulation  needs  to  make  an  LOS  determination 


5 


during  the  simulation  run,  it  simply  uses  the  given  sensor-to-target  range,  sensor 
elevation,  and  terrain  type  to  determine  the  probability  that  LOS  exists  using  the  FLOS 
look-up  table.  Subsequently,  a  simple  uniform  random  number  draw  and  comparison  to 
the  FLOS  will  determine  whether  LOS  exists. 


Figure  3.  Illustration  of  Sensor-To-Target  Range 

Thus,  FLOS  requires  the  same  data  as  traditional  LOS  algorithms,  but  it  is  less 
accurate  (a  traditional  LOS  algorithm  is  deterministic,  while  computing  LOS  using  FLOS 
estimates  is  stochastic).  The  reason,  then,  for  even  considering  the  use  of  FLOS  is  that 
traditional  LOS  algorithms  necessitate  the  use  of  computationally  expensive 
computations  during  the  simulation,  increasing  run  time.  FLOS  calculations,  in  contrast, 
require  the  use  of  computationally  expensive  calculations  during  pre-processing  and 
computationally  inexpensive  table  look-ups  during  the  simulation.  Thus,  if  there  is  an 
ample  pre-processing  time  budget  for  a  simulation,  the  use  of  a  FLOS  methodology  can 
greatly  reduce  simulation  run  time. 
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PLOS  is  clearly  not  appropriate  for  simulations  involving  few  entities  and  few 
events  or  interactions  -  traditional  LOS  algorithms  will  suffice.  However,  when  the 
number  of  entities  and  interactions  becomes  large,  simulation  run  time  can  become 
unaeceptably  long.  In  these  situations,  it  may  be  worthwhile  to  saerifiee  LOS  accuracy  in 
order  to  reduee  simulation  run  time.  It  is  in  exaetly  these  situations  that  a  PLOS 
methodology  ean  be  useful. 

2.  PLOS  Curves 

A  PLOS  eurve  is  simply  a  plot  of  PLOS  versus  sensor-to-target  range.  All  other 
variables,  such  as  sensor  elevation,  target  elevation,  and  terrain  type,  are  fixed  for  a  given 
PLOS  curve.  Thus,  PLOS  curves  eonsolidate  PLOS  estimates  in  graphieal  form  and 
provide  a  visual  picture  of  how  PLOS  behaves  as  a  function  of  range.  An  example  of  a 
PLOS  curve  is  shown  in  Figure  4.  PLOS  curves  will,  in  general,  be  monotonic 
decreasing  -  we  would  expeet  PLOS  to  deerease  as  range  increases.  The  shape  of  PLOS 
eurves,  however,  will  vary.  PLOS  curves  may  be  linear,  piecewise  linear,  coneave, 
convex,  or  a  eombination  of  these  shapes  (as  shown  in  Figure  4). 


Figure  4.  Example  of  a  PLOS  Curve 
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3,  Joint  Warfare  System  Use  of  PLOS 

The  Joint  Warfare  System  (JWARS)  is  a  eampaign-level  model  of  military 
operations  that  has  been  developed  for  use  by  the  Offiee  of  the  Secretary  of  Defense,  the 
Joint  Staff,  the  Services,  and  the  Warfighting  Commands  (Stone,  2001).  Because  of  a 
willingness  to  sacrifice  LOS  accuracy  in  order  to  improve  simulation  run  time,  JWARS 
currently  employs  a  PLOS  methodology  for  combat  scenarios  in  open  terrain.  In 
JWARS,  PLOS  is  a  function  of  three  parameters:  sensor-to-target  range,  sensor  elevation, 
and  effective  terrain  roughness.  The  third  parameter,  effective  terrain  roughness,  is  a 
function  of  sensor-to-target  range  and  the  aggregate  qualities  of  the  underlying  terrain; 
more  detailed  information  on  the  calculation  of  effective  terrain  roughness  can  be  found 
in  (Blacksten,  2002)  and  (Blacksten,  2004). 

The  PLOS  estimates  computed  by  JWARS  are  approximated  by  fitting  a 
functional  approximation  to  the  PLOS  data  (using  the  sensor-to-target  range,  sensor 
elevation,  and  effective  terrain  roughness  as  parameters)  rather  than  using  a  PLOS  look¬ 
up  table.  Consequently,  when  JWARS  needs  to  perform  a  LOS  calculation,  it  does  not 
explicitly  calculate  LOS  based  on  a  comparison  of  slopes.  Instead,  it  simply  evaluates  a 
function  in  order  to  determine  the  probability  that  LOS  exists  -  the  PLOS.  Then,  as 
previously  described,  a  uniform  random  number  draw  and  comparison  to  the  PLOS  will 
stochastically  determine  whether  LOS  exists. 

As  demonstrated  by  JWARS,  the  use  of  PLOS  in  combat  simulations  that  model 
open  terrain  is  not  a  novel  idea;  however,  at  the  time  of  this  research,  a  PLOS 
methodology  had  yet  to  be  applied  to  urban  terrain. 

B,  OBJECTIVES 

The  ultimate  objective  of  this  research  is  to  determine  the  usefulness  of  a  PLOS 
methodology  for  urban  combat  simulations.  In  order  to  accomplish  this,  our  intent  is  to 
develop  a  product  that  allows  for  rapid  LOS  determination  for  many  sensors  and  many 
targets  in  an  urban  combat  simulation  through  the  generation  and  use  of  urban  PLOS 
look-up  tables  or  closed-form  functions. 

Specifically,  our  research  focuses  on  the  following  goals: 
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1.  Explore  how  the  PLOS  methodology  developed  for  open  terrain  ean  be 
adapted  to  produee  PLOS  estimates  for  urban  terrain. 

2.  Develop  a  prototype  simulation  that  will  generate  PLOS  estimates  for  a  given 
range,  sensor  elevation,  and  urban  terrain  type. 

3.  Determine  how  urban  PLOS  behaves  as  a  function  of  range,  sensor  elevation, 
and  urban  terrain  type  via  analysis  of  urban  PLOS  curves. 

4.  Identify  topics  unique  to  urban  PLOS  to  which  further  research  should  be 
dedicated. 

C.  THE  URBAN  PLOS  PROTOTYPE  SIMULATION 

1,  Urban  PLOS  Parameters 

In  leveraging  the  PLOS  methodology  employed  by  JWARS  for  open  terrain,  we 
continue  to  use  range  and  sensor  elevation  as  the  two  baseline  parameters  for  computing 
urban  PLOS  estimates.  However,  when  considering  urban  terrain,  where  buildings  would 
seem  to  be  the  predominant  obstruction  to  LOS,  terrain  roughness  does  not  seem  to  be  an 
appropriate  parameter.  In  place  of  the  terrain  roughness  factor,  we  use  an  Urban  Terrain 
Zone  (UTZ)  classification  as  the  third  factor  in  our  computations  of  urban  PLOS 
estimates. 

2,  Urban  Terrain  Classification 

Richard  Ellefsen  of  San  Jose  State  University  developed  the  UTZ  classification 
system  currently  used  by  the  United  States  Army.  UTZ  classifications  are  determined  by 
factors  such  as  building  dimensions,  building  spacing,  construction  types,  and  street 
widths.  Additional  information  on  UTZs  and  the  UTZ  classification  system  can  be  found 
in  (Ellefsen,  1987).  The  UTZ  classifications  suggested  by  Ellefsen  essentially  provide  a 
set  of  “rules”  which  a  particular  urban  area  is  expected  to  obey  in  order  to  earn  a  given 
UTZ  classification.  Thus,  many  different  urban  areas  may  all  be  assigned  the  same  UTZ 
classification,  as  long  as  they  all  conform  to  the  rule  set  proposed  for  the  given  UTZ 
classification. 
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Army  Materiel  Systems  Analysis  Aetivity  (AMSAA)  and  TerraSim  have  been 
working  to  construct  geotypical  urban  templates:  terrain  templates  that  obey  the  rule  sets 
proposed  by  Ellefsen,  and,  thus,  are  representative  of  each  UTZ.  These  geotypical  urban 
templates  are  not  representative  of  any  specific  urban  area;  they  only  characterize  a 
particular  UTZ  classification.  Additionally,  these  geotypical  urban  templates  do  not  have 
an  underlying  terrain  skin  -  they  simply  display  buildings  resting  on  a  flat  surface.  It  is 
exactly  these  geotypical  urban  templates  that  we  used  to  perform  our  urban  PLOS 
experiments. 


3.  Simulation  Assumptions  and  Limitations 

Before  our  development  of  the  prototype  simulation,  we  make  several  simplifying 
assumptions.  Once  the  simulation  is  coded  and  the  results  validated,  these  assumptions 
can  then  be  relaxed  in  order  to  provide  additional  insight  into  urban  PLOS. 

1.  Only  buildings  can  block  LOS  (the  effect  of  underlying  terrain  skin, 
vegetation,  vehicles,  lampposts,  etc.  is  omitted). 

2.  Buildings  can  be  of  any  shape,  but  each  building’s  height  must  be  uniform 
(each  building  must  have  a  fiat  roof). 

3.  LOS  is  considered  in  all  directions  (360  degrees)  from  each  sensor  location. 

4.  Sensors  and  targets  are  not  located  inside  buildings  -  only  LOS  exterior  to 
buildings  is  considered. 

5.  Only  ground-level  targets  are  considered. 

4.  Data 

At  the  time  of  this  research,  there  were  three  geotypical  urban  templates  available 
on  which  we  could  perform  urban  PLOS  experiments.  These  geotypical  urban  templates 
were  each  750  meters  long  by  750  meters  wide  and  were  named  the  City  Core,  Outlying 
High-Rise  Area,  and  Commercial  Ribbon.  Overhead  views  of  these  three  urban 
templates  are  shown  in  Ligures  5,  6,  and  7,  respectively.  The  City  Core  urban  template  is 
densely  populated  with  high-rise  buildings.  The  Outlying  High-Rise  Area  contains 
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buildings  of  similar  heights  to  those  of  the  City  Core,  but  is  more  sparsely  populated  with 
buildings.  The  Commercial  Ribbon  is  sparsely  populated  with  smaller  buildings  (no 
more  than  six  stories  tall)  and  contains  a  central  main  street  area.  The  minimum  building 
height,  maximum  building  height,  mean  building  height,  and  fraction  of  land  area 
covered  by  buildings  in  each  urban  template  is  summarized  in  Table  1. 


□ 

□ 


Concrete  Block 


Brick,  Mass  Constraction 


Wood  Frame 


Concete,  Brick,  and  Glass  Cladding 


Poured  Concrete 


BrickyStone,  Mass  Constiniction 


Concrete  Block,  Brick  Cladding 


Concrete  Block,  Masonry  Cladding 


Glass  and  Steel  Cladding 


Stone,  Mass  Constraction 


Concrete/Glass  Cladding 


Figure  5.  Overhead  View  of  City  Core  Urban  Template  (From  ref.  Fordyce,  2003) 
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All  buildings 
have  steel  frames 

I  Biick  aiid  Glass  Cladding 
B  Glass  and  Steel  Cladding 
I  Concrete,  Biick  and  Glass  Cladding 
I  I  Concrete  and  Glass  Cladding 
B  Landscaped 


Figure  6.  Overhead  View  of  Outlying  High-Rise  Area  Urban  Template  (From  ref. 

Fordyce,  2003) 


Wood  Frame 
Brick  mass  const. 

I  I  Concrete  Block 
Concrete  Tilt-Up 
Stone  mass  const. 


Figure  7.  Overhead  View  of  Commercial  Ribbon  Urban  Template  (From  ref 

Fordyce,  2003) 
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Min  Building 
Height  (meters) 

Max  Building 
Height  (meters) 

Mean  Building 
Height  (meters) 

Coverage 

Faetor* 

City  Core 

10.97 

146.30 

31.13 

0.57 

Outlying  High- 

Rise  Area 

14.63 

109.73 

39.13 

0.26 

Commereial 

Ribbon 

3.66 

21.95 

9.82 

0.30 

*Fraction  of  Ground  Covered  By  Buildings 

Table  1 .  Summary  Statistics  for  Each  Urban  Template 

The  data  used  for  our  urban  PEGS  experiments  is  in  the  form  of  a  Microsoft 
Excel  spreadsheet  with  building  locations  and  dimensions  for  each  geotypical  urban 
template.  An  example  of  this  data  for  the  City  Core  urban  template  is  shown  in  Eigure  8. 
Each  line  of  the  spreadsheet  contains  information  on  one  particular  building  -  it  details 
(1)  the  X-  and  y-coordinate  of  each  of  the  four  comers  of  the  building,  and  (2)  the  height 
of  the  building  in  stories.  The  wall  composition  of  each  building  is  also  included  in  these 
files,  but  it  is  not  used  for  our  calculations  of  urban  PEGS  estimates.  These  spreadsheets 
are  converted  into  standard  text  files  and  used  as  the  input  files  for  our  prototype 
simulation. 
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Figure  8.  Microsoft  Excel  Spreadsheet  with  Building  Data  for  City  Core  Urban 

Template 

5.  Simulation  Implementation 

The  Urban  PEGS  Prototype  Simulation  (UPPS)  that  we  developed  to  compute 
PEGS  estimates  for  urban  terrain  is  written  in  the  Java  programming  language  using  an 
object-oriented  approach.  The  UPPS  Java  code  only  generates  PEGS  estimates;  it  does 
not  construct  PEGS  curves.  The  statistical  package  S-Plus  was  used  to  generate  the 
PEGS  curves  depicted  in  this  thesis;  for  more  information  on  S-Plus  see  (Notes  on  S- 
Plus,  2004).  Appendix  A  contains  a  “User’s  Manual”  with  more  detailed  information  on 
the  development  and  the  instructions  for  use  of  the  UPPS.  The  Java  code  of  the  UPPS 
can  be  found  in  Appendix  B. 

The  UPPS  employs  a  Monte  Carlo  simulation  in  order  to  determine  PEGS 

estimates  for  each  range,  sensor  elevation,  and  terrain  type.  First,  building  data  for  an 

14 


urban  template  (similar  to  that  in  Figure  8)  is  provided  to  the  UPPS  as  an  input  file. 
Next,  the  sensor  elevation  is  fixed.  One  sensor  (at  the  fixed  elevation)  and  one  target  (at 
zero  elevation)  are  uniformly  randomly  plaeed  in  the  urban  template.  Then,  a  traditional 
LOS  algorithm,  using  eomparison  of  slopes,  is  applied  to  determine  if  the  sensor  has  LOS 
to  the  target.  This  proeess  is  then  replieated  for  a  suffieiently  large,  user-determined 
number  of  sensor-target  pairs.  The  results  are  sorted  by  the  range  between  sensor  and 
target  and  plaeed  in  range  bins.  Subsequently,  the  fraction  of  sensor-target  pairs  for 
which  LOS  is  achieved  in  each  range  bin  is  calculated;  this  quantity  is  the  PLOS  for  the 
given  range  bin,  sensor  elevation,  and  terrain  type.  An  illustration  of  how  these  PLOS 
values  are  calculated  is  shown  in  Figure  9.  This  entire  process  is  then  repeated  for  a  new, 
fixed  sensor  elevation. 


27 

PLOS =—=0.6 
45 


PLOS =—  =  0.51 
35 


PLOS =—=0.4 

20 


Figure  9.  Illustration  of  PLOS  Calculations  in  the  UPPS 
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D,  RESULTS  AND  ANALYSIS 


1,  PLOS  Curves  for  each  Urban  Template 

For  each  of  the  three  geotypical  urban  templates  available,  we  used  the  UPPS  to 
calculate  PLOS  estimates  for  several  different  sensor  elevations  and  ranges.  For  each 
sensor  elevation,  ten  million  different  sensor-target  pairs  were  used  to  calculate  PLOS 
estimates.  These  ten  million  sensor-target  pairs  were  sorted  into  bins  of  five-meter  size 
(0-5  meter  bin,  5-10  meter  bin,  etc.).  Figure  10  is  a  plot  showing,  for  one  particular 
sensor  elevation  and  terrain  type  combination,  the  number  of  sensor-target  pairs  resulting 
in  each  range  bin;  a  plot  for  all  other  sensor  elevation/terrain  type  combinations  exhibited 
the  same  shape.  When  analyzing  the  results,  ranges  longer  than  750  meters  were  not 
considered  because  of  the  limiting  size  of  the  urban  templates  -  the  templates  were  not 
large  enough  to  provide  a  sufficient  variety  in  the  geometry  of  line  segments  longer  than 
750  meters.  While  the  shape  of  the  histogram  in  Figure  10  is  not  “uniform,”  the  large 
number  of  sensor-target  pairs  generated  virtually  ensured  that  each  bin  of  line  segments 
shorter  than  750  meters  would  contain  at  least  1000  observations  -  a  sufficient  number  of 
observations  for  the  purposes  of  this  work.  Follow-on  work  in  this  area  could  focus  on 
refining  the  UPPS  to  generate  a  more  uniform  distribution  of  ranges.  The  output  data 
from  the  UPPS  was  then  used  to  generate  PLOS  curves  for  each  terrain  type. 
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Number  of  Observations 


Figure  10.  Illustration  of  the  Number  of  Observations  in  Each  Range  Bin 

a.  City  Core 

For  the  City  Core  urban  template  (shown  in  Figure  5),  we  used  the  UPPS 
to  calculate  PFOS  estimates  for  sensor  elevations  ranging  from  0  to  2500  meters  (target 
elevation  was  zero  for  all  cases).  The  plot  in  Figure  11  shows  a  sampling  of  10  PFOS 
curves  that  were  generated  for  the  City  Core  urban  template. 
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Figure  11.  PLOS  Curves  for  10  Sensor  Elevations  in  the  City  Core  Urban  Template 


We  now  present  three  observations  eoneeming  the  City  Core  PLOS  eurves 
depieted  in  Figure  11.  First,  note  that  the  PLOS  eurve  for  zero  elevation  is  higher  than 
PLOS  eurves  for  higher  sensor  elevations  for  low  ranges.  In  other  words,  this  indieates 
that  a  sensor  has  a  higher  probability  of  having  LOS  to  a  target  when  it  is  loeated  on  the 
ground  than  when  it  is  above  ground.  This  eonelusion  seems  eounter-intuitive,  but  we 
have  devised  a  theory  that  might  explain  this  strange  oceurrence.  Initially,  we  note  that 
the  PLOS  curve  for  a  sensor  elevation  of  zero  will  be  identical  to  that  of  any  PLOS  curve 
for  a  sensor  elevation  lower  than  the  height  of  the  shortest  building.  Figure  12  will  help 
to  explain  this  concept.  For  any  sensor-target  location  combination  (where  the  target 
elevation  is  zero),  the  evaluation  of  LOS  will  be  same  for  any  sensor  elevation  lower  than 
the  height  of  the  shortest  building  (the  same  buildings  will  always  impede,  or  not  impede, 
LOS).  Thus,  with  all  of  the  LOS  evaluations  being  the  same,  the  resulting  PLOS 
estimates  will  be  the  same  for  any  sensor  elevation  lower  than  the  height  of  the  shortest 
building. 
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Figure  12.  Illustration  of  Why  PLOS  Might  Increase  as  Sensor  Elevation  Decreases 

Now,  consider  moving  the  sensor  elevation  from  an  elevation  lower  than 
the  height  of  the  shortest  building  to  an  elevation  slightly  above  the  height  of  the  shortest 
building.  Looking  at  Figure  12,  we  can  see  that  elevating  the  sensor  above  the  height  of 
the  shortest  building  has  introduced  more  sensor  locations  to  consider;  specifically,  those 
sensor  locations  in  region  A  of  Figure  12.  The  sensor  locations  in  region  A  have  a  low 
PLOS,  since  building  B  effectively  blocks  LOS  to  most  ground-level  targets.  Thus,  these 
additional  sensor  locations  allowed  by  the  increase  in  sensor  elevation  may  decrease  the 
total  PLOS  estimate,  potentially  making  it  worse  than  for  a  lower  sensor  elevation. 

A  second  observation  is  that  the  PLOS  curves  for  high  (relative)  sensor 
elevations  actually  increase  as  range  increases  on  certain  portions  of  the  curve.  This  is 
completely  counter-intuitive  -  we  would  expect  that  as  the  sensor-to-target  range 
increases,  the  PLOS  value  would  decrease,  not  increase.  While  we  have  not  done 
thorough  testing  to  evaluate  this  issue,  we  have  again  developed  a  theory  to  explain  this 
phenomenon.  Consider  a  sensor  located  directly  above  a  building,  as  depicted  in  Figure 
13.  This  sensor  does  not  have  LOS  to  targets  that  are  within  a  range  of  r.  However, 
when  the  range  to  the  target  is  greater  than  r,  the  sensor  will  have  LOS  to  the  target. 
Thus,  increasing  the  range  from  sensor  to  target  in  this  case  has  improved  the  chance  that 
the  sensor  has  LOS  to  the  target.  This  simple  illustration  can  help  explain  why  PLOS 
might  increase  as  range  increases. 
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Figure  13.  Illustration  of  Why  PLOS  May  Increase  as  Range  Increases 

A  final  observation  is  that  the  PLOS  curves  in  Figure  11  seem  to  have 
different  shapes  for  low,  medium,  and  high  sensor  elevations.  This  would  suggest  that 
when  trying  to  approximate  these  curves  with  an  analytical  function,  one  might  consider 
using  three  different  types  of  analytical  functions  to  approximate  -  one  for  low  sensor 
elevations  (lower  than  the  height  of  the  shortest  building),  one  for  medium  sensor 
elevations  (within  the  range  of  building  heights  -  higher  than  the  shortest  building,  but 
lower  than  the  tallest  building),  and  one  for  high  sensor  elevations  (higher  than  the  tallest 
building). 
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b.  Outlying  High-Rise  Area 

The  plot  in  Figure  14  shows  a  sampling  of  10  PLOS  curves  that  were 
generated  for  the  Outlying  High-Rise  Area  urban  template  (shown  in  Figure  6).  Note  that 
these  are  the  same  sensor  elevations  as  for  the  City  Core  urban  template. 


Figure  14.  PLOS  Curves  for  10  Sensor  Elevations  in  the  Outlying  High-Rise  Area 

Urban  Template 
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We  now  present  three  observations  concerning  the  Outlying  High-Rise 
Area  PLOS  curves  depicted  in  Figure  14.  First,  just  as  with  the  City  Core  PLOS  curves, 
we  again  find  that  the  PLOS  curve  for  zero  elevation  is  higher  than  PLOS  curves  for 
higher  sensor  elevations  for  low  ranges.  The  same  explanation  for  why  this  happened 
with  our  City  Core  PLOS  curves  may  explain  why  this  happens  for  the  Outlying  High 
Rise  Area  PLOS  curves,  as  well.  Second,  we  note  that,  similar  to  the  City  Core  PLOS 
curves,  the  Outlying  High-Rise  Area  PLOS  curves  seem  to  have  different  shapes  for  low, 
medium,  and  high  sensor  elevations  -  this  would  suggest  using  different  types  of 
analytical  functions  in  order  to  approximate  these  curves.  Finally,  we  note  that  the  PLOS 
curves  for  high  (relative)  sensor  elevations  seem  to  be  almost  linear  over  the  set  of  ranges 
that  we  tested. 


c.  Commercial  Ribbon 

The  plot  in  Figure  15  shows  a  sampling  of  12  PLOS  curves  that  were 
generated  for  the  Commercial  Ribbon  urban  template  (shown  in  Figure  7).  The  sensor 
elevations  used  to  construct  these  curves  were  different  from  those  used  for  the  City  Core 
and  Outlying  High  Rise  Area  urban  templates.  The  Commercial  Ribbon  urban  template 
had  much  shorter  buildings;  thus,  it  was  appropriate  that  we  focus  our  attention  on  a 
“lower”  set  of  sensor  elevations. 


22 


1.0  - 


0.8  - 


0.6  - 


o 

_l 

Q. 


0.4  - 


0.2  - 


0.0  - 


Elev.O 

Elev.10 

Elev.20 

Elev.30 

Elev.40 

Elev.50 

Elev.75 

Elev.100 

Elev.150 

Elev.200 

Elev.500 

Elev.1000 


0  100  200  300  400  500  600  700  800 

Range  (meters) 


Figure  15.  PLOS  Curves  for  12  Sensor  Elevations  in  the  Commereial  Ribbon  Urban 

Template 


We  now  present  three  observations  concerning  the  Commercial  Ribbon 
PLOS  curves  depicted  in  Figure  15.  First,  just  as  with  the  City  Core  and  Outlying  High- 
Rise  Area  PLOS  curves,  we  again  find  that  the  PLOS  curve  for  zero  elevation  is  higher 
than  PLOS  curves  for  higher  sensor  elevations  for  low  ranges.  Second,  we  note  once 
more  that  the  Commercial  Ribbon  PLOS  curves  seem  to  have  different  shapes  for  low, 
medium,  and  high  sensor  elevations  and  might  require  different  classes  of  functions  to 
approximate.  Finally,  as  with  the  Outlying  High-Rise  Area  PLOS  curves,  we  see  that  the 
Commercial  Ribbon  PLOS  curves  for  high  (relative)  sensor  elevations  seem  to  be  almost 
linear  over  the  set  of  ranges  that  we  tested. 
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d.  Comparison  ofPLOS  Curves  For  All  Three  Urban  Templates 
The  next  logieal  step  in  our  analysis  was  a  simple  comparison  of  FLOS 
curves  with  identical  sensor  elevations  but  different  urban  template  classifications. 
Figure  16  shows  the  FLOS  curve  of  each  urban  template  for  a  50-meter  sensor  elevation 
(left)  and  a  200-meter  sensor  elevation  (right).  Not  surprisingly,  these  plots  demonstrate 
that  the  Commercial  Ribbon  urban  template  is  the  “dominant”  urban  template  for  LOS  - 
it  has  a  higher  FLOS  estimate  for  any  given  range  than  do  the  other  two  urban  templates. 
Also,  as  we  might  expect,  the  City  Core  urban  template  is  the  “worst”  urban  template  for 
LOS.  Similar  plots  to  those  in  Figure  16  for  different  sensor  elevations  yielded  the  same 
ordinal  results. 


PLOS  Curves  for  Sensor  Elevation  50  Meters 


PLOS  Curves  for  Sensor  Elevation  200  Meters 


Figure  16.  FLOS  Curves  for  Each  Urban  Template  for  Sensor  Elevation  50  Meters 

(left)  and  200  Meters  (right) 
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2,  Comparison  of  UPPS  PLOS  Estimates  to  PLOS  Estimates  Generated 
With  Combat  XXI 

Generating  urban  PLOS  estimates  with  the  UPPS  was  certainly  an 
accomplishment,  but  how  could  we  be  certain  that  these  urban  PLOS  estimates  were 
accurate?  We  wanted  a  “second  opinion”  that,  at  least  on  a  superficial  level,  would 
provide  us  with  some  confidence  that  the  urban  PLOS  estimates  produced  by  the  UPPS 
were  precise.  We  found  an  existing  entity-level  combat  simulation.  Combat  XXI,  to  be 
useful  in  obtaining  this  “second  opinion.” 

Combat  XXI  is  a  replacement  and  upgrade  for  Combined  Arms  and  Support  Task 
Evaluation  Model  (CASTFOREM),  the  Army’s  highest  resolution,  lowest  echelon, 
systemic,  combined  arms  combat  simulation  model  (Army  MSRR,  2004).  Combat  XXI 
is  capable  of  representing  urban  terrain  and  has  its  own  LOS  algorithm  in  order  to 
evaluate  battlefield  encounters.  We  used  existing  Combat  XXI  code  (with  a  few 
modifications)  and  its  LOS  algorithm  to  generate  PLOS  estimates  for  some  of  the  same 
ranges,  sensor  elevations,  and  terrain  types  as  we  did  with  the  UPPS.  The  code  used  to 
generate  these  urban  PLOS  estimates  with  Combat  XXI  can  be  found  in  Appendix  C.  As 
an  example  of  our  results.  Figure  17  shows  a  comparison  of  the  PEOS  estimates 
generated  by  the  UPPS  and  Combat  XXI  for  the  Commercial  Ribbon  and  Outlying  High- 
Rise  Area  urban  templates  with  sensor  elevations  of  100  and  200  meters,  respectively. 
(We  performed  many  other  comparison  plots  for  different  ranges,  sensor  elevations,  and 
terrain  types;  however,  we  do  not  display  them  in  this  paper.) 


PLOS  Comparison:  Commercial  Ribbon,  Sensor  Elevation  100 


PLOS  Comparison:  Outlying  High  Rise  Area,  Sensor  Elevation  200 


0  100  200  300  400  500  600  700 

Range  (meters) 


0  100  200  300  400  500  600  700  800 

Range  (meters) 


Figure  17.  Comparison  of  PEOS  Estimates  Generated  By  the  UPPS  and  Combat  XXI 
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The  similarity  of  the  FLOS  estimates  that  we  eomputed  using  Combat  XXI  to  the 
FLOS  estimates  eomputed  with  the  UFFS  should  in  no  way  be  considered  a  validation  of 
the  UFFS;  instead,  they  should  simply  be  considered  a  “sanity  check”  for  verifying  the 
accuracy  of  the  FLOS  estimates  generated  by  the  UFFS.  Nonetheless,  the  FLOS 
estimates  computed  using  Combat  XXI  are  at  least  a  first  step  in  the  validation  of  the 
UFFS.  In  that  respect,  it  is  encouraging  to  note  that  the  two  sets  of  FLOS  estimates 
computed  (the  UFFS  and  Combat  XXI)  never  differed  by  more  than  0.08  for  any  of  the 
ranges,  sensor  elevations,  and  terrain  types  that  we  tested.  The  exact  reason  for  the 
differences  the  two  sets  of  FLOS  estimates  is  unclear  at  this  point  in  our  work;  this  is  a 
subject  to  which  further  research  should  be  dedicated. 

3,  Effect  of  Change  in  Target  Elevation 

Once  we  were  successful  at  generating  FLOS  curves  with  ground-level  targets,  it 
was  natural  to  extend  the  UFFS  to  handle  elevated  targets.  The  UFFS  was  modified  to 
allow  the  user  to  vary  the  target  elevation  while  keeping  the  sensor  elevation  fixed.  For 
example,  one  can  generate  FLOS  curves  for  each  combination  of  sensor  elevation  and 
target  elevation.  Specifically,  this  would  allow  one  to  explore  FLOS  curves  for  rooftop 
targets.  It  should  be  noted,  however,  that  the  introduction  of  target  elevation  necessitates 
the  use  of  an  extra  parameter  in  our  construction  of  FLOS  curves;  FLOS  curves  generated 
for  a  specific  target  elevation  require  four  parameters:  range,  sensor  elevation,  terrain 
type,  and  target  elevation. 

4.  Effect  of  Underlying  Terrain  Skin 

In  developing  the  UFFS,  we  made  the  assumption  that  only  buildings  could  block 
LOS  by  omitting  the  underlying  terrain  skin.  Now,  the  question  arises:  does  underlying 
terrain  skin  make  a  substantial  difference  when  calculating  urban  FLOS  estimates?  We 
enlisted  the  help  of  AMSAA  and  TerraSim  to  help  us  take  the  available  geotypical  urban 
templates  and  mount  them  on  an  underlying  terrain  skin.  Figure  18  shows  an  example  of 
the  results  of  this  “mounting”  -  it  depicts  the  City  Core  urban  template  with  an 
underlying  terrain  skin. 
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Figure  18.  City  Core  Urban  Template  With  an  Underlying  Terrain  Skin  (From  ref. 

MeKeown,  2003) 

A  full  analysis  of  the  effeet  of  underlying  terrain  skin  was  not  completed  in  this 
work;  however  we  nonetheless  suggest  an  experimental  design  by  which  one  would  study 
these  effects.  Specifically,  one  would  construct  pairs  of  PLOS  curves  for  fixed  sensor 
elevations  in  each  of  the  three  available  urban  templates.  Of  each  pair  of  PLOS  curves, 
one  would  be  constructed  omitting  the  underlying  terrain  skin  (assuming  a  flat  underlying 
surface);  the  second  would  be  constructed  using  elevation  data  after  mounting  the  urban 
template  on  a  non-flat  underlying  terrain  skin.  Each  pair  of  PLOS  curves  can  then  be 
statistically  analyzed  to  determine  if  there  are  significant  differences  in  PLOS  estimates 
when  including  the  underlying  terrain  skin. 
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5,  Time  Until  LOS  is  Gained  or  Lost 

In  this  research,  our  simulation  runs  focused  on  stationary  sensors  and  targets. 
Thus,  the  urban  PLOS  estimates  that  we  have  generated  using  the  UPPS  are  only  valid 
for  a  particular  point  in  time.  As  an  extension,  we  explored  how  we  could  use  our  urban 
PLOS  estimates  to  approximate  the  time  until  LOS  is  gained  or  lost  for  moving  targets  in 
an  urban  environment.  Specifically,  we  accomplished  this  by  deriving  a  cumulative 
distribution  function  (CDF)  for  the  time  until  LOS  is  gained  and  lost  for  a  particular 
sensor  elevation  and  urban  terrain  type. 

a.  Assumptions 

In  deriving  our  CDFs,  we  made  the  following  assumptions: 

1.  Sensor  is  stationary  (thus,  its  elevation  is  fixed). 

2.  Urban  terrain  type  is  fixed. 

3.  The  target  is  moving  (thus,  its  range  to  the  sensor  is  changing). 

4.  Successive  LOS  “attempts”  by  the  sensor  are  independent. 

b.  Variables 

Tq  time  until  LOS  is  gained 

time  until  LOS  is  lost 

Tq  initial  range  from  sensor  to  target 

r(?)  change  in  sensor-target  range  in  a  time  of  t 

R  set  of  ranges  at  which  sensor- target  LOS  is  evaluated 

(note:  this  is  an  infinite  set  of  ranges  -  it  includes 

all  ranges  in  the  interval  [fi),rQ  -f  r(?)] ) 

PLOS{r)  PLOS  for  sensor-target  range  r  (remember,  urban  terrain 

type  and  sensor  elevation  are  already  fixed) 
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c.  CDF  for  the  Time  Until  LOS  is  Gained 

P{T^<t}  =\-P{T^>t} 

-\-  P{LOS  is  never  gained  during  time  t] 

-\- P{LOS  is  never  gained  along  the  target  path} 

=  l-n(l--PiOS(r)) 

reR 

=  1  -  exp|ln|j^(l  -  PZ.OS(r))|| 

=  l-exp|xln{(l-raOS(r))}| 


=  l-exp 


jln{(l-PZ05'(r))}r/r 


d.  CDF  for  the  Time  Until  LOS  is  Lost 

P{T^<t]  =\-P{T^>t\ 

=  1  -  P{LOS  is  maintained  during  time  t\ 

-\- P{LOS  is  maintained  along  the  target  path} 

^l-Y[PLOSir) 

reR 

-I-  exp  jin  PLOS  (r) 

=  1  -  exp  j  ^ln{PZ(95'(r)} 


=  1 


exp 


^\n{PLOS{r)}dr 
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e.  Use  of  CDFs  in  a  Combat  Simulation 

Just  as  our  PLOS  estimates  ean  be  calculated  during  the  pre-processing 
phase  of  a  combat  simulation,  so  can  the  estimates  proposed  by  the  CDFs  for  the  time 
until  LOS  is  gained  or  lost.  Since  the  integrals  in  the  equations  of  these  CDFs  are 
unlikely  to  have  a  closed  form  solution,  a  simulation  would  need  to  use  a  numerical 
approximation  to  evaluate  these  integrals;  specific  methods  for  approximating  definite 
integrals  numerically  can  be  found  in  (Gerald,  1999).  Once  these  CDFs  are  generated 
during  preprocessing,  a  simple  uniform  random  number  draw  and  comparison  to  the  CDF 
could  be  used  to  schedule  the  time  when  LOS  is  gained  or  lost  in  a  discrete  event 
simulation.  Additionally,  using  these  CDFs,  it  would  be  easy  to  simulate  a  target  that 
alternates  between  being  visible  and  hidden.  Once  LOS  to  a  target  is  gained,  the  time 
until  LOS  is  lost  could  be  compared  to  times  required  for  a  sensor  to 
classify/detect/identify  a  target  to  determine  if  the  target  has  been  visible  long  enough  to 
be  placed  into  a  “higher”  acquisition  state. 
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III.  STOCHASTIC  AND  ANALYTICAL  MODELS  FOR  TARGET 
ACQUISTION  IN  URBAN  TERRAIN 

A,  BACKGROUND 

Many  current  combat  simulations  model  urban  target  aequisition  at  the  entity- 
level.  These  models  are  extremely  time-intensive,  as  they  evaluate  the  target  acquisition 
outcome  of  each  sensor-target  combination  on  the  battlefield.  Combine  this  with  the  fact 
that,  in  general,  these  target  acquisition  models  use  physies-based  and/or  computationally 
expensive  algorithms  to  determine  the  target  acquisition  outcome  for  each  sensor-target 
encounter,  and  the  result  is  a  combat  simulation  that  can  take  a  long  time  to  execute  for 
large-scale  urban  combat  scenarios.  With  an  important  aspect  of  current  and  future 
military  operations  being  in  an  urban  setting,  entity-level  target  acquisition  models  will 
only  become  more  cumbersome. 

The  complexities  encountered  in  urban  target  aequisition  modeling  largely 
parallel  those  of  attrition  modeling.  When  approached  from  the  entity-level,  attrition 
modeling  is  also  extremely  time-intensive  and  can  become  computationally  expensive  in 
a  combat  simulation.  However,  combat  simulation  developers  have  found  ways  to 
simplify  calculations  of  attrition,  and,  in  the  proeess,  have  improved  the  run  time  of  their 
simulations.  Specifically,  some  eurrent  combat  simulations,  such  as  Combat  XXI  and 
CASTFOREM,  use  probabilities  of  hit  and  probabilities  of  kill  in  plaee  of 
computationally  expensive  algorithms  of  attrition  modeling.  For  example,  instead  of  a 
eombat  simulation  using  a  physics-based  algorithm  to  determine  if  a  round  fired  from  a 
friendly  tank  hits  an  enemy  tank  (an  algorithm  that  might  use,  for  example,  round 
trajectory,  weather  conditions,  and  obscuration  effects  in  its  calculations),  the  simulation 
simply  uses  a  probability  of  hit  and/or  probability  of  kill  to  determine  the  extent  of  the 
damage  caused  by  the  fired  round.  Probabilities  of  hit  and  kill  are  determined  in  pre¬ 
processing  and  are  subsequently  accessed  during  the  simulation  either  via  a  table  look-up 
or  analytical  function  evaluation  based  on  a  few  predetermined  parameters,  such  as  range, 
round  type,  and  target  type. 
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B,  OBJECTIVES 

The  objective  of  this  research  is  to  develop  stochastic  and  analytical  target 
acquisition  models  whose  outputs  could  be  used  in  place  of  computationally  expensive 
urban  target  acquisition  algorithms  in  existing  and  emerging  combat  simulations  to 
provide  for  faster  simulation  time  while  yielding  an  acceptable  compromise  in  accuracy 
on  the  aggregate  level.  In  a  sense,  we  are  seeking  the  urban  target  acquisition  equivalent 
to  probabilities  of  hit  and  probabilities  of  kill  used  in  attrition  modeling. 

Specifically,  we  aim  to  develop  mathematical  models  for  aggregate  urban  target 
acquisition  that  would  use  data  derived  from  high  resolution  simulations  as  inputs  in 
order  to  rapidly  estimate  desired  quantities  and,  in  turn,  provide  insight  into  the  following 
areas: 

1.  Estimating  the  proficiency  of  a  given  set  of  sensors  against  a  given  set  of 
targets  in  a  specific  urban  area. 

2.  Determining  the  number  and  mix  of  sensors  required  to  achieve  a  certain  level 
of  “dominance”  in  a  particular  urban  area. 

3.  Providing  suggested  employment  strategies  for  sensors. 

C.  PROPOSED  MODELS 

1.  Cumulative  Distribution  Function  Model 

The  goal  of  this  model  is  to  estimate  the  proficiency  of  a  given  set  of  sensors 
against  a  given  set  of  targets  in  a  particular  urban  area.  In  this  section,  the  term 
"detection"  is  used  to  generically  represent  any  level  of  target  acquisition.  It  can  be 
replaced  everywhere  by  another  type  of  target  classification,  say,  "recognition"  or 
"identification,"  and  similar  models  would  apply. 


a.  Problem  Description 

A  large  number  of  sensors  (the  "blue"  force)  are  arrayed  against  a  large 

number  of  targets  (the  "red"  force)  in  a  particular  urban  Area  of  Operations  (AO).  The 
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blue  force  knows  the  number  and  type  of  sensors  it  has  available,  but  does  not  know  the 
number  and  type  of  targets  that  exist  in  the  AO. 

b.  Model  Objectives 

Our  model  is  designed  to  answer  the  following  questions: 


1.  How  many  (and  which)  targets  are  detected  hy  a  given  set  of 
sensors  in  a  given  time  period? 


2,  How  many  (and  what  type  of)  sensors  will  it  take  to  detect  a 
certain  percentage  of  targets  in  a  given  time  period? 

c.  Approach 

Many  existing  models  used  in  current  combat  simulations  are  certainly 
capable  of  answering  these  questions;  however,  they  would  often  use  time-intensive, 
computationally  expensive  algorithms  to  do  so.  Our  approach  to  answering  the  two 
questions  above  is  radically  different:  we  develop  an  aggregate  target  acquisition  model 
that  significantly  reduces  the  number  of  calculations  required  to  estimate  desired 
quantities.  Specifically,  rather  than  seeking  a  deterministic  answer  to  the  above 
questions,  we  instead  pursue  a  stochastic  answer.  For  example,  to  answer  Question  #1, 
we  will  derive  a  general  expression  that  describes  the  distribution  of  the  number  and  type 
of  targets  detected  (from  which  we  can  generate  the  number  and  type  of  targets  detected 
for  any  particular  instance). 

d.  Model  Development 

Assume  we  have  a  large  number  of  blue  force  sensors  arrayed  against  a 
large  number  of  red  force  targets  in  a  particular  AO.  The  blue  force  is  comprised  of  a  set 
of  sensor  packages,  S ,  each  consisting  of  one  or  more  sensor  platforms.  Each  sensor 
platform,  in  turn,  consists  of  different  types  of  sensor  assets.  A  concise  description  of  the 
relationship  between  individual  sensors,  sensor  platforms,  and  sensor  packages  is  given 
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in  (Tutton,  2003).  Each  red  force  target  is  categorized  as  being  of  a  particular  type;  we 
let  T  be  the  set  of  target  types.  Figure  19  shows  an  example  of  a  complete  set  of  sensors 
and  targets  in  our  model. 
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Figure  19.  An  Example  Set  of  Sensors  and  Targets  for  the  Cumulative  Distribution 

Function  Model 

In  conducting  intelligence-gathering  operations  prior  to  battle,  the  blue 

force  will  begin  by  partitioning  the  AO  into  n  named  areas  of  interest  (NAIs)  that  will  be 

searched  by  its  sensor  assets.  We  will  assume  that  the  NAIs  do  not  exhaust  the  entire 

AO.  Now,  since  the  blue  force  does  not  have  complete  knowledge  of  the  red  force,  there 

will  certainly  be  targets  that  are  not  contained  in  any  NAI.  Thus,  the  set  of  targets  will 

effectively  be  partitioned  into  n+\  target  clusters  {n  clusters  of  the  set  of  targets 

contained  in  each  of  the  NAIs  and  one  cluster  of  the  set  of  targets  that  are  not  contained 
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in  any  NAI).  We  will  call  this  set  of  target  clusters  C .  We  assume,  in  this  paper,  that  a 
decision  tool  exists  and  is  used  by  the  blue  force  commander  for  partitioning  the  area  of 
operations  into  NAIs  (and,  thus,  the  set  of  targets  into  clusters).  An  example  of  how  an 
AO  might  be  partitioned  into  NAIs  is  given  in  Figure  20. 
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In  the  AO  pictured  above,  there  are  4  NAIs  (bounded  by  the  rectangles). 
Thus,  the  set  of  targets  would  be  partitioned  into  5  target  clusters. 


Figure  20.  An  Example  of  How  an  AO  Might  be  Partitioned  Into  NAIs  (From  ref. 

Tutton,  2003) 
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Now,  there  are  |C|  target  clusters  that  the  blue  force  has  classified  as 
“eligible”  for  search  by  its  sensor  assets  (we  may  assume  that  |C|  >  |tS| ,  in  general).  We 

must  also  assume,  in  a  worst  case,  that  each  target  cluster  would  contain  all  jj’l  different 

types  of  targets.  Figure  21  summarizes  our  problem  by  removing  the  “map”  containing 
the  AO  and  NAIs  and  depicting  only  sensors  and  targets. 
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Figure  21.  Partitioning  the  Set  of  Targets  into  Target  Clusters 
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The  blue  foree  will  assign  its  sensor  paekages  to  seareh  each  NAI  (each 
NAI  will  have  at  most  one  sensor  package  assigned  to  search  it).  We  again  assume  that  a 
decision  tool  exists  and  is  used  by  the  blue  force  for  optimally  assigning  sensor  packages 
to  NAIs;  an  example  of  such  a  decision  tool  is  given  in  (Tutton,  2003).  Figure  22 
elaborates  on  Figure  21,  exhibiting  an  allocation  of  sensor  packages  to  target  clusters. 
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Figure  22.  An  Allocation  of  Sensor  Packages  to  Target  Clusters 
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Now,  each  sensor  package  will  be  searching  for  potentially  jT’l  different 
target  types.  Thus,  the  allocation  of  sensor  packages  to  NAIs  effectively  divides  our 
problem  into  ItS"!  •  [T’I  subproblems  (we  have  ■  IT’]  sensor  package/target  type 

combinations  to  investigate).  We  will  focus  our  attention  on  one  of  these  general 
subproblems,  depicted  in  Figure  23.  We  will  first  derive  an  answer  to  the  following 
question;  how  many  targets  of  type  t  in  target  cluster  c  are  detected  by  sensor  package  5 
in  a  given  time  period?  We  will  label  the  answer  to  this  question  as  . 


Sensor 
Package  3 


o  o 


Targets  of  Type  2  in 
Target  Cluster  1 


Figure  23.  A  Subproblem  in  the  Cumulative  Distribution  Function  Model 

Again,  rather  than  seeking  a  deterministic  answer  to  the  above  question, 
we  instead  pursue  a  stochastic  answer.  Specifically,  we  will  derive  a  cumulative 
distribution  function  (CDF)  that  describes  the  distribution  of  how  many  targets  are 
detected.  Then,  for  any  particular  subproblem,  a  simple  random  number  draw  and 
comparison  to  the  CDF  will  generate  a  value  of  .  (This  explains  why  we  have  used  a 
capital  letter  X  to  label  this  quantity  -  it  is  a  random  variable  in  our  model.) 

Rather  than  assuming  that  each  sensor  acts  independently  of  the  other 
sensors  in  sensor  package  5,  we  instead  assume  that  we  can  aggregate  the  sensors  in 
sensor  package  s  and  effectively  treat  them  as  a  single  sensor  (the  manner  in  which  this  is 
done  is  at  the  discretion  of  the  modeler;  specific  examples  can  be  found  in  (Tutton,  2003) 
and  (Driels,  2001).  Thus,  we  can  think  of  sensor  package  5  (now  considered  a  single, 
aggregated  sensor)  as  having  the  opportunity  to  detect  each  target  in  the  NAI  to  which  it 
is  assigned.  Let  be  the  number  of  targets  of  type  t  in  target  cluster  c.  We  can  view 
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the  search  by  sensor  package  5  for  targets  of  type  t  in  target  cluster  c  as  independent 
searches  for  targets. 

We  are  now  ready  to  begin  calculation.  Let  be  the  probability  that  a 
target  of  type  t  in  target  cluster  c  is  detected  by  sensor  package  5  in  a  given  time  period 
(this  time  period  should  be  the  same  for  all  ).  We  can  assume  that  we  are  able  to 

calculate  these  probabilities  of  detection  for  each  target  type/target  cluster/sensor  package 
combination  (or  that  these  probabilities  of  detection  have  already  been  calculated  and  can 
be  referenced  in  a  table)  and  that  the  same  target  type/target  cluster/sensor  package 
combination  will  always  yield  the  same  probability  of  detection.  The  way  in  which  these 
probabilities  of  detection  are  calculated  is  at  the  discretion  of  the  modeler.  Parameters 
that  might  be  used  to  calculate  these  probabilities  of  detection  are  (1)  the  search  time 
available  to  the  sensor  package,  (2)  the  size  of  the  NAI,  (3)  the  "effectiveness"  of  the 
sensor  package,  (4)  the  number  and  type  of  sensors  in  the  package,  (5)  the  number  and 
type  of  targets  in  the  target  cluster.  For  an  example  of  how  these  probabilities  might  be 
calculated  for  a  given  sensor  package  and  target  cluster,  see  (Tutton,  2003)  or  (Driels, 
2001). 

Again,  our  aggregation  model  assumes  that  the  values  of  p^^^  can  be 
calculated;  it  does  not  depend  on  how  they  were  calculated.  Figure  24  shows  these 
probabilities  of  detection  applied  to  our  model. 


Sensor 
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Figure  24.  Probabilities  of  Detection  Applied  to  the  Cumulative  Distribution 

Function  Model 
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Once  a  probability  of  detection  is  assigned  to  eaeh  target,  we  can  perform 
a  binomial  probability  calculation  to  determine  the  probability  of  deteeting  any  number  of 
targets  of  eaeh  type.  Specifically,  we  can  say  that 


j 


This  probability  distribution  can  be  transformed  into  a  CDF  using  the 
following  expression; 


P{X„<y}  =  Y,P{X„=x}. 

x<y 

Thus,  in  order  to  generate  a  particular  value  of  ,  we  would  draw  a 
uniform  random  number  in  the  interval  [0,l)  -  label  this  random  number  u.  Next,  we 
would  compare  u  to  the  values  of  our  CDF;  the  smallest  value  of  x  for  which 
^{.^tcs  ^x]>U  will  be  our  generated  value  of  (the  number  of  targets  of  type  t  in 
target  cluster  c  detected  by  sensor  package  5  in  a  given  time  period). 

Now,  having  generated  X^^^,  we  can  address  another  question:  which 

targets  of  type  t  in  target  eluster  c  are  detected  by  the  sensor  paekage  s  in  the  given  time 
period?  Since  we  have  assumed  that  all  sensor  package/target  type  encounters  in  the 
same  NAI  would  be  assigned  the  same  probability  of  detection,  we  can  answer  this 
question  by  simply  randomly  selecting  X^^^  targets  from  the  targets  of  type  t  in 
cluster  c. 

We  can  perform  the  same  ealculations  above  for  every  target  type/target 
eluster/sensor  paekage  combination,  sequentially  deriving  CDFs  (|iS|  •  jj’l  of  them)  from 
which  we  can  generate  values  of  X^^^  and,  in  turn,  randomly  generate  which  targets  are 

deteeted.  This  proeedure  will  preeisely  answer  our  first  question;  how  many  (and  whieh) 
targets  are  deteeted  by  a  given  set  of  sensors  in  a  given  time  period? 
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Now,  without  knowledge  of  exaetly  how  eaeh  sensor  paekage  was 
aggregated  into  a  single  sensor,  we  eannot  easily  determine  how  many  and  what  type  of 
sensors  are  required  to  detect  a  certain  percentage  of  targets  (our  second  question). 
Instead,  we  propose  a  method  by  which  the  blue  force  can  heuristically  analyze  several 
courses  of  action  (the  number  of  type  of  sensors  employed)  and  decide  which  is  the  best 
to  fit  its  mission  requirements. 

The  blue  force  would  first  need  to  decide  on  a  decision  criterion  (or 
measure  of  effectiveness  (MOE))  that  will  be  used  to  decide  whether  or  not  a  certain  set 
of  sensors  is  “better”  than  another  for  a  given  scenario.  Next,  the  blue  force  can  propose 
several  “candidate”  sets  of  sensors  for  use  in  the  AO.  Then,  the  model  we  have 
developed  above  (to  answer  our  first  question)  could  be  applied  for  each  candidate.  The 
output  values  of  each  MOE  could  be  statistically  analyzed  to  provide  a  decision-maker 
with  a  summary  of  how  well  each  set  of  sensors  would  perform.  Thus,  we  have  not 
answered  our  second  question  explicitly,  but  we  have  instead  proposed  a  method  by 
which  the  blue  force  can  evaluate  the  strengths  and  weaknesses  of  several  candidate  sets 
of  sensors  quickly  through  the  use  of  our  existing  model. 

2,  Target  Acquisition  State  Transition  Models 

The  goal  of  these  models  is  to  represent  the  “movement”  of  a  target  between 
different  acquisition  states.  The  model  proposed  in  this  paper  uses  four  acquisition  states: 
Eindetected,  Detected,  Recognized,  and  Identified.  Similar  models  could  be  developed 
for  any  number  and  names  of  acquisition  states,  though  the  complexity  of  the  model  will 
increase  with  the  addition  of  each  acquisition  state. 

A  target  is  considered  to  be  undetected  if  it  is  not  detected  at  the  present  time;  all 
targets  in  our  models  are  always  considered  to  be  initially  undetected.  A  target  becomes 
detected  when  a  sensor  perceives  an  object  of  possible  military  interest  that  is 
unconfirmed  by  recognition  (JP  1-02,  2001).  The  detected  target  becomes  recognized 
only  when  it  is  determined  that  it  is  similar  within  a  category  of  something  already 
known;  e.g.  tank,  truck,  man  (JP  1-02,  2001).  In  other  words,  if  a  detected  target  can  be 
classified  as  being  of  a  given  category  of  objects,  then  it  has  been  recognized.  We  note 
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here  that,  by  definition,  detection  is  a  “prerequisite”  for  recognition.  The  recognized 
target,  in  turn,  becomes  identified  only  when  a  sensor  is  able  to  discriminate  it  as  being 
friendly  or  enemy,  and/or  is  able  to  assign  a  name  that  belongs  to  that  target  as  a  member 
of  a  class  (JP  1-02,  2001).  Again,  we  note  here  that,  by  definition,  recognition  is  a 
prerequisite  for  identification. 


a.  Problem  Description 

An  aggregated  sensor  package  is  searching  for  one  target  in  a  particular 
NAI  representative  of  a  specific  urban  terrain  type. 


b.  Model  Objectives 

Our  models  are  designed  to  answer  the  following  questions: 


1,  What  is  the  prohahility  that  a  target  hecomes  detected,  recognized, 
or  identified  in  a  given  amount  of  time? 


2,  How  long  does  it  take  a  target  to  transition  from  one  acquisition 
state  to  another? 


target? 


3.  How  much  time  will  it  take  to  detect,  recognize,  or  identify  a 


c.  Approach 

Existing  models  used  in  current  combat  simulations  are  capable  of 
answering  these  questions;  however,  they  would  likely  use  time-intensive, 
computationally  expensive  algorithms  to  do  so.  Our  approach  to  answering  the  three 
questions  above  will  be  the  same  as  for  our  Cumulative  Distribution  Function  Model  - 
rather  than  seeking  a  deterministic  answer,  we  instead  pursue  a  stochastic  answer.  For 

example,  to  answer  Question  #2,  we  will  develop  a  model  from  which  we  can  estimate 
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the  distribution  of  transition  times  between  aequisition  states  (from  whieh  we  ean 
generate  a  transition  time  for  any  partieular  instanee).  Additionally,  our  intent  is  to  use 
data  from  high-resolution  simulation  runs  in  order  to  estimate  desired  quantities  and 
ultimately  answer  the  above  questions. 

We  will  develop  two  distinet  models:  (1)  a  Diserete  Time  Markov  Chain 
Model,  and  (2)  an  Event  Step  Model.  The  goal  of  the  Diserete  Time  Markov  Chain 
Model  will  be  to  estimate  the  probabilities  of  transitioning  from  one  aequisition  state  to 
another  in  a  given  time,  while  the  goal  of  the  Event  Step  Model  will  be  to  estimate  the 
transition  times  between  aequisition  states. 

d.  Model  Development  -  The  Discrete  Time  Markov  Chain  Model 

A  Diserete  Time  Markov  Chain  is  a  stoehastie  proeess  that  takes  on  a 
finite  or  eountable  number  of  possible  values.  The  possible  values  that  the  proeess  may 
take  are  referred  to  as  “states.”  Whenever  the  proeess  is  in  state  i,  there  is  a  fixed 
probability,  P^j ,  ealled  a  “single-step  transition  probability,”  that  the  proeess  will  next  be 

in  state  j  (this  probability  is  eonditionally  independent  of  all  past  states  the  proeess  has 
visited  given  that  the  proeess  is  in  state  i  at  the  present  time).  Additional  information  on 
Diserete  Time  Markov  Chains  ean  be  found  in  (Ross,  2003). 

In  partieular,  for  our  target  aequisition  problem,  we  have  four  states: 
Undeteeted,  Deteeted,  Reeognized,  and  Identified.  A  target  in  any  one  of  these  states  ean 
transition  to  any  other  state.  If  we  assume  that  the  probability  of  a  target  moving  from 
one  aequisition  state  to  another  is  conditionally  independent  of  the  past  given  its  present 
state,  then  a  Discrete  Time  Markov  Chain  can  be  developed  to  model  the  movement  of  a 
target  through  acquisition  states.  Eigure  25  is  a  pictorial  representation  of  this  Discrete 
Time  Markov  Chain. 
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Figure  25.  Discrete  Time  Markov  Chain  Model  of  Target  Acquisition  States 

Each  arc  in  Figure  25  has  a  single-step  transition  probability  associated 
with  it.  Each  single-step  transition  probability  is  the  probability  that  the  target  moves 
along  this  arc  (from  the  state  at  the  “tail”  of  the  arc  to  the  state  at  the  “head”  of  the  arc)  in 
the  next  time  step.  For  example,  is  the  probability  that  the  target  transitions  from  the 

Undetected  state  to  the  Detected  state  in  one  time  step  (these  probabilities  are  not  shown 
in  Figure  25  for  fear  that  they  would  clutter  the  picture).  Typically,  in  a  Discrete  Time 
Markov  Chain,  these  single-step  transition  probabilities  are  known.  In  our  case,  however, 
these  single-step  transition  probabilities  are  unknown  -  they  are  the  quantities  that  we 
want  to  estimate. 

Estimating  the  single-step  transition  probabilities  of  our  model  was  not  a 
goal  of  this  research;  however,  we  nonetheless  present  an  experimental  design  that  would 
allow  one  to  estimate  these  probabilities  by  using  a  suitable  combat  simulation.  First,  we 
note  that  the  single-step  transition  probabilities  that  we  seek  to  find  will  likely  depend  on 
three  factors;  the  composition  of  the  sensor  package  executing  the  search,  the  type  of 
target  for  which  the  sensor  package  is  searching,  and  the  UTZ  classification  of  the  NAI 
being  searched.  Next,  we  propose  that  data  from  a  high-resolution  simulation  be  used  in 
order  to  estimate  the  single-step  transition  probabilities  for  each  sensor  package/target 
type/UTZ  classification  combination. 


45 


Now,  in  order  to  estimate  the  single-step  transition  probabilities  for  one 
sensor  package/target  type/UTZ  elassifieation,  one  would  use  an  approaeh  similar  to  a 
Monte  Carlo  simulation;  pseudo  eode  for  this  proeess  can  be  found  in  Figure  26. 
Specifically,  one  would  build  a  scenario  in  a  high-resolution  simulation  by  selecting  a 
sensor  package,  target  type,  and  UTZ  classification  for  the  NAI.  A  large  number  of 
targets  of  the  selected  target  type  should  initially  be  placed  in  an  Undetected  state.  Prior 
to  starting  the  simulation,  a  time  step  size.  At ,  should  be  selected  (it  is  not  necessary, 
here,  that  At  be  a  small  number;  large  values  of  At  may  be  useful,  as  well).  Then,  one 
would  allow  the  simulation  to  run  (allowing  the  sensor  package  to  search  for  all  targets) 
for  many  time  steps.  During  the  simulation,  the  state  of  each  target  at  the  end  of  each 
time  step  should  be  recorded.  Thus,  upon  completion  of  the  simulation,  one  would  have 
data  that  shows,  for  each  target,  the  acquisition  state  of  the  target  after  each  time  step. 
Table  2  shows  an  example  of  recorded  data  from  a  hypothetical  simulation  run  to 
estimate  single-step  transition  probabilities. 


for  each  terrain  type  { 

FOR  EACH  SENSOR  PACKAGE  { 

for  each  target  type  (T)  { 

INITIALIZE  MANY  TARGETS  OF  TYPE  T 
PLACE  ALL  TARGETS  IN  UNDETECTED  STATE 
SELECT  A  TIME  STEP  SIZE 

SELECT  A  SIMULATION  RUN  TIME  (MANY  TIME  STEPS) 
BEGIN  THE  HIGH-RESOLUTION  SIMULATION  { 
for  EACH  TIME  STEP  { 

FOR  EACH  TARGET  { 

RECORD  THE  STATE 


}  END  THE  HIGH-RESOLUTION  SIMULATION 


Figure  26.  Pseudo  Code  for  Estimating  Single-Step  Transition  Probabilities 
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Time  Step  5 

Target  1 

U 

D 

R 

I 

U 

Target  2 

U 

U 

I 

U 

D 

Target  3 

U 

D 

U 

D 

U 

Target  4 

U 

R 

I 

I 

I 

Target  5 

U 

I 

I 

U 

D 

Target  6 

U 

U 

D 

D 

D 

Target  7 

u 

U 

U 

U 

U 

U  =  Undetected  D  =  Detected  R  =  Recognized  I  =  Identified 

Table  2.  Data  From  a  Hypothetical  Simulation  Run  to  Estimate  Single-Step  Transition 

Probabilities 


If  we  let  t  be  the  number  of  targets  and  n  be  the  number  of  time  steps, 
then  the  data  in  Table  2  essentially  represents  t-n  state  transitions.  For  each  of  these 
state  transitions,  we  know  the  beginning  state  and  the  ending  state.  Thus,  in  order  to 
calculate  the  single-step  transition  probabilities  from  data  such  as  that  in  Table  2,  we  first 
need  to  sort  all  of  these  state  transitions  by  the  beginning  state.  For  our  simple  model,  we 
would  have  four  sets  of  state  transitions:  those  beginning  in  the  Undetected,  Detected, 
Recognized,  and  Identified  states,  respectively.  Then,  for  the  transitions  beginning  in  the 
Undetected  state,  we  can  further  sort  by  the  ending  state  and  count  the  number  of 
transitions  that  end  at  the  Undetected,  Detected,  Recognized,  and  Identified  states, 
respectively.  Each  of  these  four  numbers  can  then  be  divided  by  the  total  number  of 
transitions  beginning  in  the  Undetected  state  to  estimate  each  of  the  single-step  transition 
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probabilities  for  transitions  emanating  from  the  Undeteeted  state.  Figure  27  illustrates  a 
sample  ealeulation  of  this  type. 


After  one  time  step. . . 


Figure  27.  Sample  Caleulation  of  Single-Step  Transition  Probabilities 

We  ean  repeat  these  ealeulations  for  transitions  beginning  in  all  other 
states  in  order  to  estimate  all  of  the  single-step  transition  probabilities  of  our  model.  This 
entire  proeess  eould  then  be  repeated  for  a  different  sensor  paekage/target  type/UTZ 
elassifieation.  Onee  the  single-step  transition  probabilities  have  been  ealeulated,  one  ean 
use  the  analytieal  results  on  Diserete  Time  Markov  Chains  presented  in  (Ross,  2003)  to 
answer  Questions  #1  and  #3  asked  of  this  model. 

e.  Model  Development  -  The  Event  Step  Model 

Our  Event  Step  Model  is  similar  to  a  Diserete  Time  Markov  Chain,  but 
eaeh  are  has  a  single-step  transition  time  assoeiated  with  it  instead  of  a  single-step 
transition  probability.  Thus,  in  order  to  develop  our  Event  Step  Model,  we  retain  the  four 
aequisition  states,  but  reformat  the  ares  in  our  pieture;  this  Event  Step  Model  is  illustrated 
in  Eigure  28.  In  our  Diserete  Time  Markov  Chain  Model,  the  target  ean  “jump”  to  any 
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state  in  a  single  time  step.  However,  when  modeling  this  process  using  an  Event  Step 
model,  we  assume  that  the  target  must  proceed  sequentially  through  the  acquisition  states 
(from  Undetected  to  Detected  to  Recognized  to  Identified)  -  the  target  is  not  permitted  to 
“skip”  an  acquisition  state.  The  reason  me  make  this  assumption  stems  purely  from  the 
fact  that,  as  mentioned  earlier,  the  definitions  of  (JP  1-02,  2001)  suggest  a  “hierarchy”  of 
acquisition  states  that  should  be  followed.  However,  instead  of  moving  successively  to 
the  next  “higher”  acquisition  state,  the  target  could  become  Undetected,  effectively 
starting  the  problem  over  again.  Typically,  in  an  Event  Step  Model,  the  transition  times 
between  states  are  known.  In  our  case,  however,  these  transition  times  are  unknown  - 
they  are  the  quantities  that  we  want  to  estimate. 


U  =  Undetected  D  =  Detected  R  =  Recognized  I  =  Identified 


Eigure  28.  Event  Step  Model  of  Target  Acquisition  States 

Just  as  with  our  Discrete  Time  Markov  Chain  Model,  estimating  the 
single-step  transition  times  was  not  a  goal  of  this  research;  however,  we  nonetheless 
present  an  experimental  design  that  would  allow  one  to  estimate  these  probabilities  by 
using  a  suitable  combat  simulation.  As  with  the  Discrete  Time  Markov  Chain  Model,  we 
assume  that  the  single-step  transition  times  that  we  seek  to  find  will  be  different  for  each 
sensor  package/target  type/UTZ  classification  combination,  and  we  propose  that  data 
from  a  high-resolution  simulation  be  used  in  order  to  estimate  the  single-step  transition 
times  for  each  of  these  combinations. 
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Now,  in  order  to  estimate  the  single-step  transition  times  for  one  sensor 
paekage/target  type/UTZ  elassifieation,  one  would  again  use  an  approaeh  similar  to  a 
Monte  Carlo  simulation;  pseudo  eode  for  this  proeess  ean  be  found  in  Figure  29. 
Specifically,  one  would  build  a  scenario  in  a  high-resolution  simulation  by  selecting  a 
sensor  package,  target  type,  and  UTZ  classification  for  the  NAI.  A  large  number  of 
targets  of  the  selected  target  type  should  initially  be  placed  in  an  Undetected  state.  Then, 
one  would  allow  the  simulation  to  run  (allowing  the  sensor  package  to  search  for  all 
targets)  for  a  sufficient  length  of  time.  Whenever  any  target  undergoes  a  state  change 
during  the  simulation,  the  new  state  of  the  target  should  be  recorded  as  well  as  the  current 
simulation  time.  Thus,  upon  the  termination  of  the  simulation,  one  would  have,  for  each 
target,  a  list  of  the  states  visited  and  the  time  spent  in  each  state.  Table  3  shows  an 
example  of  recorded  data  from  a  hypothetical  simulation  run  to  estimate  single-step 
transition  times. 

At  the  end  of  the  simulation  run,  one  can  then  calculate  statistics  on  the 
transition  times  (such  as  the  mean  and  variance)  recorded  for  each  ending  acquisition 
state.  This  will  give  an  estimate  as  to  the  expected  transition  time  to  each  state  as  well  as 
insight  as  to  the  distribution  of  transition  times  to  each  state.  This  entire  process  could 
then  be  repeated  for  a  different  sensor  package/target  type/UTZ  classification.  Once 
these  single-step  transition  times  (and  distributions  of  single-step  transition  times)  have 
been  calculated,  one  can  use  simple  calculations  to  answer  Questions  #2  and  #3  of  this 
model. 
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FOR  EACH  TERRAIN  TYPE  { 

FOR  EACH  SENSOR  PACKAGE  { 

FOR  EACH  TARGET  TYPE  (T)  { 

INITIALIZE  MANY  TARGETS  OF  TYPE  T 
PLACE  ALL  TARGETS  IN  UNDETECTED  STATE 
SELECT  A  SIMULATION  RUN  TIME 

BEGIN  THE  HIGH-RESOLUTION  SIMULATION  { 

FOR  EACH  STATE  TRANSITION  { 

RECORD  THE  NEW  STATE  OF  THE  TARGET 
RECORD  THE  SIMULATION  TIME 


)  END  THE  HIGH-RESOLUTION  SIMULATION 


} 


} 


Figure  29.  Pseudo  Code  for  Estimating  Single-Step  Transition  Times 


Transition  1  / 

Simulation  Time 

Transition  2  / 

Simulation  Time 

Transition  3  / 

Simulation  Time 

Transition  4  / 

Simulation  Time 

Transition  5  / 

Simulation  Time 

Target  1 

D/4.5 

U/5.7 

D/ 17.4 

R/ 17.4 

1/17.4 

Target  2 

D/0.5 

U/ 1.5 

D/3.6 

U/6.6 

D/6.8 

Target  3 

D/ 10.5 

R/ 14.0 

1/14.5 

U/39.9 

D  /  44.6 

Target  4 

D/8.7 

R/8.7 

U/8.9 

D/39.0 

R/41.4 

U  =  Undetected  D  =  Detected  R  =  Recognized  I  =  Identified 


Table  3.  Data  From  a  Hypothetical  Simulation  Run  to  Estimate  Single-Step  Transition 

Times 
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3,  Aggregate  Flow  Model 


a.  Problem  Description 

A  large  number  of  sensors  are  arrayed  against  a  large  number  of  targets  in 
a  particular  AO.  The  blue  force  knows  the  number  and  type  of  sensors  it  has  available, 
but  does  not  know  the  number  and  type  of  targets  that  exist  in  the  AO. 


b.  Model  Objectives 

Our  model  is  designed  to  answer  the  following  questions: 


1.  How  many  targets  are  detected,  recognized,  or  identifled  at  any 

given  time? 


2,  What  is  the  rate  of  change  in  the  number  of  targets  detected, 
recognized,  or  identified  at  any  given  time? 


3.  How  is  this  rate  of  change  dependent  upon  the  number  of  targets 
in  each  state  at  a  given  time? 

c.  Approach 

Our  approach  to  answering  the  three  questions  above  will  be  significantly 
different  than  that  of  our  first  two  models.  For  this  model,  we  will  model  the  “flow”  of 
targets  between  acquisition  states  using  a  system  of  differential  equations.  In  essence,  we 
will  be  seeking  the  urban  target  acquisition  equivalent  to  Lanchester’s  equations  for 
attrition  modeling.  Lanchester’s  equations  propose  that  the  rate  at  which  a  force  is 
depleted  is  proportional  to  the  size  of  the  enemy  force  and  the  individual  capability  of  the 
enemy.  More  detailed  information  on  Lanchester’s  equations  can  be  found  in  (Taylor, 
1983).  In  our  model,  we  will  develop  equations  that  relate  the  rate  at  which  targets  enter 
a  given  acquisition  state  to  the  number  of  targets  in  each  acquisition  state. 
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d.  Model  Development 

As  in  our  previous  models,  we  eonsider  four  aequisition  states  for  targets: 
Undetected,  Detected,  Recognized,  and  Identified.  However,  we  realize  that  there  is  the 
possibility  that  a  target  may  not  be  in  any  of  these  states;  specifically,  once  it  has  been 
killed.  Thus,  in  order  to  account  for  all  targets,  we  can  add  a  fifth  acquisition  state: 
Killed  (alternatively,  we  could  allow  for  targets  “leaving”  the  system).  Next,  we 
represent  the  “flow”  of  targets  from  one  acquisition  state  to  another  using  arcs  to  connect 
the  acquisition  states;  this  representation  is  shown  in  Figure  30. 


Figure  30.  A  Representation  of  the  Flow  of  Targets  Between  Acquisition  States 

At  this  point,  a  few  clarifications  of  Figure  30  are  required.  First,  in  this 
model,  a  target  is  allowed  to  “skip”  acquisition  states  (for  example,  a  target  can  jump 
from  the  Undetected  state  to  the  Recognized  state,  effectively  skipping  the  Detected 
state).  We  adopt  this  convention  because  we  will  be  considering  time  steps  in  this  model 
(as  in  the  Discrete  Time  Markov  Chain  Model),  not  event  steps  (as  in  the  Event  Step 
Model).  Additionally,  we  note  that  a  target  cannot  leave  the  Killed  state  -  this  state 
effectively  allows  us  to  keep  the  total  number  of  targets  in  the  system  constant  at  any 
given  time. 
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Let  X.  be  the  number  of  targets  in  state  i  at  a  given  time.  Then  is  the 

instantaneous  rate  of  ehange  of  the  number  of  targets  in  state  i  with  respeet  to  time. 
Now,  we  eonsider  the  “balanee  of  flow”  at  eaeh  aequisition  state.  The  rate  of  ehange  of 
the  number  of  targets  in  state  i  for  a  given  time  period  is  equal  to  the  number  of  targets 
entering  state  i  in  that  time  period  minus  the  number  of  targets  leaving  state  i  in  that 
time  period.  It  is  prudent  to  assume  that  the  number  of  targets  entering  and  leaving  state 
i  in  a  given  time  period  would  be  dependent  upon  the  number  of  targets  in  each  state  at 
the  beginning  of  the  time  period. 

We  further  assume  in  the  development  of  this  model,  that  the  number  of 
targets  entering  and  leaving  eaeh  state  in  a  given  time  period  is  linearly  dependent  on  the 
number  of  targets  in  eaeh  state  at  the  beginning  of  the  time  period.  While  this 
assumption  may  seem  to  be  impraetical,  it  should  be  noted  that  Lanehester’s  basie 
equations  for  attrition  modeling  assume  linear  relationships,  and  Lanchester’s  models 
have  certainly  proven  over  time  to  be  a  good  predictor  of  attrition. 


Thus,  we  conjecture  that  the  instantaneous  rate  of  change  of  the  number  of 
targets  in  state  i  at  time  t  is  linearly  dependent  upon  the  number  of  targets  in  each  state 
at  time  t.  This  conjecture  allows  us  to  formulate  a  system  of  differential  equations 
modeling  the  flow  of  targets.  For  our  particular  model,  we  have  five  differential 
equations  (one  for  each  acquisition  state): 


■  ^UU^U  ^UD^D  ^UR^R  ^UI^I  ^UK^K 


■  ^DU^U  ^DD^D  ^DR^R  ^DI^I  ^DK^K 


dXjj 

dt 

dXjj 

dt 

dxj^  _ 

TT  ~  ^RU^U  ^RD^D  ^RR^R  ^RI^I  ^RK^K 

dt 

dx, 

——  —  ajjjXy  +  a^j^Xj^  +  ajj^Xj^  +  a^Xj  +  aj^^Xf. 

dt 


dx 


dt 


K  _ 


^KU^U  ^KD^D  ^KR^R  ^KI^I  ^KK^K  ' 
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(The  coefficients  in  the  above  equations  are  “acquisition  coefficients” 

dx- 

that  simply  describe  the  extent  of  the  linear  relationship  between  — -  and  x. ;  they  are 

dt 

analogous  to  the  attrition  coefficients  of  Lanchester’s  equations.) 

A  similar  system  of  differential  equations  could  be  developed  for  a  model 
that  includes  more  or  less  acquisition  states  -  it  would  simply  involve  more  or  less 
equations.  Because  we  have  assumed  linear  relationships,  this  system  of  differential 
equations  can  be  solved  analytically  to  derive  an  equation  for  each  x^  as  a  function  of  t . 

Using  these  analytical  results,  we  can  predict  the  number  of  targets  in  each  acquisition 
state  at  a  given  time  as  well  as  the  instantaneous  rate  at  which  targets  enter  or  leave  each 
state  at  a  given  time. 

In  order  to  develop  our  model  to  completion,  however,  extensive  work 
would  need  to  be  done  to  estimate  the  acquisition  coefficients  in  the  system  of  differential 
equations.  While  we  did  not  pursue  the  estimation  of  these  acquisition  coefficients  as  a 
part  of  this  research,  we  still  propose  a  method  by  which  these  coefficients  can  be 
estimated.  First,  we  note  that  the  acquisition  coefficients  that  we  seek  to  find  will  not  be 
constant.  Instead,  they  will  likely  depend  on  four  factors:  the  composition  of  the  set  of 
sensors  executing  the  search,  the  composition  of  the  target  set  for  which  the  set  of  sensors 
is  searching,  the  UTZ  classification  of  the  AO  being  searched,  and  the  size  of  the  AO 
being  searched.  Next,  just  as  with  our  previous  models,  we  propose  that  data  from  a 
high-resolution  simulation  be  used  in  order  to  estimate  the  acquisition  coefficients  for 
each  sensor  set/target  set/UTZ  classification/AO  size  combination;  pseudo  code  for  this 
process  can  be  found  in  Figure  3 1 . 

To  estimate  the  acquisition  coefficients  for  one  combination  of  sensor  set, 
target  set,  UTZ  classification,  and  AO  size,  one  would  first  select  an  urban  template 
representative  of  a  particular  UTZ  classification  and  fix  its  size.  Next,  the  composition  of 
the  set  of  sensors  and  the  set  of  targets  should  be  fixed.  All  targets  should  be  placed  in 
the  Undetected  state  at  the  onset  of  the  simulation.  Prior  to  starting  the  simulation,  a 
sufficiently  small  time  step  size.  At ,  should  be  selected.  Then,  the  simulation  should  be 
permitted  to  run  for  an  indefinite  period  of  time.  After  each  At  time  units,  one  should 
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record  the  time,  t ,  and  the  number  of  targets  in  state  i  at  time  t ,  (t) ,  for  each  state  i . 

Table  4  shows  an  example  of  the  data  recorded  for  a  hypothetical  simulation  run  with 
At  =  l. 


FOR  EACH  TERRAIN  TYPE  { 

FOR  EACH  SENSOR  SET  { 

FOR  EACH  TARGET  SET  { 

PLACE  ALL  TARGETS  IN  UNDETECTED  STATE 
SELECT  A  TIME  STEP  SIZE 

SELECT  A  SIMULATION  RUN  TIME  (MANY  TIME  STEPS) 

BEGIN  THE  HIGH-RESOLUTION  SIMULATION  { 

FOR  EACH  TIME  STEP  { 

RECORD  THE  SIMULATION  TIME 

FOR  EACH  ACQUISITION  STATE  { 

RECORD  THE  NUMBER  OF  TARGETS 
IN  THAT  STATE 

} 

} 

}  END  THE  HIGH-RESOLUTION  SIMULATION 


Figure  3 1 .  Pseudo  Code  for  Estimating  Acquisition  Coefficients 
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t  =  0 

t=l 

t  =  2 

t  =  3 

t  =  4 

x^t) 

100 

95 

92 

87 

88 

xjt) 

0 

3 

3 

7 

6 

XR(t) 

0 

1 

2 

3 

2 

x/t) 

0 

1 

2 

2 

2 

Xj.(t) 

0 

0 

1 

1 

2 

Table  4.  Data  From  a  Hypothetical  Simulation  Run  to  Estimate  Flow  Rates  with  At  =  1 


From  the  data  in  Table  4,  one  can  then  estimate 


dx^ 

dt 


at  any  time  using  an 


approximation  of  the  derivative: 


dxi  _  X.  (t  +  At)-x.  (t) 
dt  At 


If  we  have  selected  At  small  enough,  then  this  approximation  will  be 
close  to  the  true  value  of  the  derivative.  Then,  for  each  state  i ,  and  for  any  time,  one  can 

dx- 

conduct  a  linear  regression  using  — -  as  the  dependent  variable  and  x^ ,  x^,  ,  Xj,  x^ 

dt 

as  the  independent  variables.  The  coefficients  resulting  from  the  linear  regression  are  the 
estimated  acquisition  coefficients  in  the  original  system  of  differential  equations. 

The  entire  process  described  above  for  estimating  acquisition  coefficients 
can  be  repeated  for  each  sensor  set/target  set/UTZ  classification/ AO  size  combination. 
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Once  the  aequisition  coefficients  have  been  estimated,  the  system  of  differential 
equations  in  this  model  (and  the  subsequent  derived  functions  for  each  x^  as  a  function  of 
t )  can  be  used  to  answer  the  three  questions  of  this  model. 
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IV.  ACCOMPLISHMENTS  AND  RECOMMENDED  FURTHER 

RESEARCH 


A,  ACCOMPLISHMENTS 

1,  Probability  of  Line  of  Sight  in  Urban  Terrain 

Through  the  development  and  validation  of  the  UPPS,  we  aeeomplished  our 
objeetive  of  demonstrating  that  the  PLOS  methodology  developed  and  used  for  open 
terrain  eould  be  extended  to  produee  useful  PLOS  estimates  for  urban  terrain.  The 
purpose  of  this  paper  was  not  to  perform  a  thorough  analysis  of  urban  PLOS  estimates. 
Rather,  our  intent  was  simply  to  demonstrate  the  usefulness  of  our  produet,  the  UPPS, 
and  present  some  interesting  results  unique  to  urban  PLOS  that  should  be  addressed  in 
future  researeh.  Following  is  a  summary  of  our  aeeomplishments  in  our  researeh  of 
urban  PLOS: 

1.  We  developed  the  UPPS,  demonstrating  that  the  PLOS  methodology 
developed  for  open  terrain  eould  be  extended  to  produee  PLOS  estimates  for  urban 
terrain. 

2.  We  produeed  PLOS  eurves  for  the  three  available  urban  templates 
representative  of  different  urban  terrain  types. 

3.  We  noted  how  the  urban  PLOS  eurves  we  generated  eould  likely  be 
approximated  well  with  a  simple,  analytieal,  elosed-form  funetion. 

4.  By  produeing  urban  PLOS  estimates  using  an  existing  eombat  simulation. 
Combat  XXI,  we  eondueted  a  “sanity  eheek”  to  ensure  that  the  UPPS  urban  PLOS 
estimates  were  aeeurate.  This  eomparison  ean  also  be  eonsidered  a  first  step  in  the 
validation  of  the  UPPS. 

5.  We  modified  the  UPPS  to  aeeommodate  elevated  (speeifieally,  rooftop) 
targets  and  deseribed  how  urban  PLOS  eurves  eould  be  generated  for  sensor  elevation- 
target  elevation  eombinations. 
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6.  With  the  help  of  TerraSim,  we  “mounted”  urban  templates  onto  underlying 
terrain  and  suggested  further  testing  using  the  UPPS  in  order  to  assess  how  the 
underlying  terrain  skin  affects  urban  PLOS. 

7.  We  derived  analytical  functions  that  use  urban  PLOS  estimates  to 
approximate  the  time  until  LOS  is  gained  and  lost  for  a  given  sensor  elevation  and  urban 
terrain  type. 

2,  Stochastic  and  Analytical  Models  for  Target  Acquisition  in  Urban 
Terrain 

By  developing  the  stochastic  and  analytical  models  for  urban  target  acquisition 
that  are  presented  in  this  paper,  we  met  our  objective  of  identifying  models  that  had  the 
potential  to  decrease  simulation  run  time  for  large-scale  urban  scenarios  and/or  could 
lend  insight  into  target  acquisition  in  urban  terrain.  When  developing  our  stochastic  and 
analytical  models  for  urban  target  acquisition,  it  was  not  our  intent  to  develop  our  models 
to  completion.  Instead,  we  simply  carried  out  a  superficial  exploration  and  presented  in 
this  paper  those  models  that,  in  our  opinion,  showed  promise  as  a  useful  simulation 
model  or  stand-alone  decision  tool.  Specifically,  we  developed  the  following  stochastic 
and  analytical  models  for  representing  urban  target  acquisition: 

1 .  A  cumulative  distribution  function  model  that  can  estimate  the  proficiency  of 
a  given  set  of  sensors  against  a  given  set  of  targets  in  a  particular  urban  area. 

2.  Entity-level  state  transition  models  that  can  represent  the  movement  of  a 
target  among  acquisition  states. 

3 .  An  aggregate  flow  model  that  may  be  used  to  assess  the  flow  of  targets  from 
one  acquisition  state  to  another. 

B,  RECOMMENDED  FURTHER  RESEARCH 

1,  Probability  of  Line  of  Sight  in  Urban  Terrain 

Again,  the  purpose  of  this  paper  was  not  to  carry  out  an  extensive  analysis  of 
urban  PLOS  estimates.  Instead,  we  focused  on  presenting  an  “on  the  surface” 


60 


preliminary  analysis  of  topics  relevant  to  urban  PLOS.  Following  are  urban  PLOS  topics 
to  which  further  research  should  be  dedicated: 

1 .  A  thorough  validation  (potentially  using  a  production  version  of  Combat  XXI) 
should  be  conducted  to  examine  the  accuracy  of  the  UPPS.  Additionally,  an  analysis  of 
the  differences  between  urban  PLOS  estimates  generated  by  the  UPPS  and  Combat  XXI 
should  be  completed. 

2.  Extensive  “grunt  work”  needs  to  be  done  to  generate  all  appropriate  PLOS 
curves  for  each  sensor  elevation-target  elevation  combination  for  the  three  existing  urban 
templates:  City  Core,  Commercial  Ribbon,  and  Outlying  High-Rise  Area. 

3.  A  study  should  be  done  to  assess  how  the  distribution  of  observations  into 
range  bins  (shown  in  Figure  10)  affects  urban  PLOS  estimates.  Additionally,  one  could 
pursue  whether  there  is  a  more  efficient  way  to  generate  sensor-target  pairs  that  would 
result  in  a  more  uniform  distribution  than  the  “normal-like”  distribution  seen  in  Figure 
10. 

4.  A  detailed  investigation  into  the  “strange  behavior”  of  some  of  the  urban 
PLOS  curves  should  be  completed.  Specifically,  analysis  should  be  done  to  determine 
why  PLOS  curves  for  lower  sensor  elevations  sometimes  yield  a  higher  PLOS  than  for 
higher  sensor  elevations  and  why,  for  some  curves,  PLOS  actually  increases  with  range. 

5.  Curve  fitting  should  be  carried  out  on  the  urban  PLOS  curves  for  the  available 
urban  templates  representative  of  each  UTZ  classification  in  an  attempt  to  approximate 
urban  PLOS  estimates  with  a  closed-form  function.  An  important  subproblem  is  how  to 
quantify  the  urban  terrain  type  when  developing  these  closed-form  functions.  One 
possible  solution  is  to  use  statistics  from  each  urban  template  as  parameters  (e.g.  mean 
building  height,  coverage  factor,  etc.).  Analysis  should  be  done  on  the  errors  introduced 
by  a  function  approximation  to  determine  if  the  error  is  within  an  acceptable  tolerance. 

6.  A  thorough  analysis  should  be  accomplished  to  determine  if  the  underlying 
terrain  skin  in  an  urban  area  makes  a  significant  difference  in  the  estimates  of  urban 
PLOS. 
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7.  A  validation  should  be  conducted  of  the  analytical  estimates  of  the  time  until 
LOS  gained  or  lost  suggested  in  this  research. 

2,  Stochastic  and  Analytical  Models  for  Target  Acquisition  in  Urban 
Terrain 

As  our  work  in  developing  our  stochastic  and  analytical  urban  target  acquisition 
models  was  largely  exploratory  in  nature,  there  is  obviously  a  plethora  of  additional 
research  and  “brainstorming”  to  which  further  research  could  be  dedicated.  We  present  a 
few  topics  of  additional  research  that  apply  specifically  to  the  models  developed  in  this 
paper: 

1.  Our  cumulative  distribution  function  model  should  be  further  developed  to 
answer  the  following  question:  “Given  that  a  set  of  sensors  has  detected  x  targets,  how 
many  targets  actually  exist  in  the  AO?”  If  our  cumulative  distribution  function  model  is 
extended  to  answer  this  question,  it  could  prove  to  be  an  extremely  useful  tool  for  the 
Future  Force  commander. 

2.  Testing  should  be  accomplished  to  estimate  the  single-step  transition 
probabilities  and  single-step  transition  times  proposed  by  our  entity-level  state  transition 
models  for  a  myriad  of  sensor  packages,  target  types,  and  urban  terrain  types. 

3.  Testing  should  be  accomplished  to  estimate  the  acquisition  coefficients 
suggested  by  our  aggregate  flow  model  for  different  sensor  sets,  target  sets,  and  urban 
terrain  types. 
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APPENDIX  A.  USER’S  MANUAL  FOR  THE  UPPS 


A,  UPPS  INPUT 

The  input  to  the  UPPS  is  a  text  file  of  the  format  shown  in  Figure  32.  The  first 
line  of  the  file  has  three  numbers;  the  x-dimension  of  the  urban  template,  the  y- 
dimension  of  the  urban  template,  and  the  number  of  buildings  in  the  urban  template. 
Following  is  a  line  to  describe  the  location  and  height  of  each  building  (in  the  case  of  the 
urban  template  described  by  the  text  file  in  Figure  32,  we  have  209  additional  lines).  The 
first  number  in  each  of  these  lines  is  the  number  of  corners  of  the  building. 
Subsequently,  the  x-  and  y-coordinates  of  each  comer  of  the  building  are  listed  (in  a 
clockwise  or  counterclockwise  pattern).  The  final  number  on  each  line  is  the  height  of 
the  building.  For  example,  the  first  building  listed  in  the  text  file  in  Figure  32  has  four 
comers  at  coordinates  (1,38),  (1,1),  (47,1),  and  (47,38),  respectively,  and  has  a  height  of 
29.2608  meters. 


Figure  32.  UPPS  Input  File  for  the  City  Core  Urban  Template 
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B,  UPPS  OUTPUT 

Figure  33  shows  example  output  from  the  UPPS.  The  output  file  contains  urban 
PLOS  estimates  for  one  particular  urban  template/sensor  elevation/target  elevation 
combination.  The  output  file  contains  three  columns.  The  first  column  lists  the  range 
bin,  the  second  column  lists  the  PLOS  estimate  for  that  range  bin,  and  the  third  column 
lists  the  number  of  observations  in  that  particular  range  bin.  For  example,  the  first  line  of 
this  output  file  tells  us  that  in  the  0  -  5 -meter  range  bin  there  were  1470  observations 
with  a  PLOS  estimate  of  0.9782.  The  second  line  of  this  output  file  tells  us  that  in  the  5  - 
10-meter  range  bin  there  were  4166  observations  with  a  PLOS  estimate  of  0.9618. 


Figure  33.  UPPS  Output  File  for  the  City  Core  Urban  Template,  Sensor  Elevation 

200  meters.  Target  Elevation  0  meters 
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C.  JAVA  CLASSES 

The  Java  classes  used  to  develop  the  UPPS  were  of  three  different  types:  existing 
Java  classes,  existing  Simkit  classes,  and  new  classes  developed  “from  scratch” 
specifically  for  this  simulation. 

1,  Existing  Java  Classes 

Following  is  a  list  of  the  existing  Java  classes  used  for  the  UPPS;  javadocs  for 
these  classes  can  be  found  at  http://iava.sun.eom/i2se/l.4.2/docs/api/mdex.html. 


For  reading  in  the  data: 

FileReader 

BufferedReader 

StringTokenizer 

Integer 

Double 

For  Exception  handling: 

FileNotF  oundException 
CloneNotSupportedException 
RuntimeExc  option 
Eor  basic  mathematical  operations: 
Math 

Eor  geometry  purposes: 

Polygon 

Line2D 


65 


2,  Existing  Simkit  Classes 

Simkit  is  a  Java  package  designed  for  use  in  diserete  event  simulations  (more 
information  on  Simkit  ean  be  found  at  http://diana.gl.nps.navv.mil/Simkit/).  For  the 
purposes  of  the  UPPS,  Simkit  was  used  for  random  number  generation  and  ealeulating 
statisties.  Following  is  a  list  of  the  existing  Simkit  elasses  used  in  the  UPPS;  javadoes  for 
these  elasses  can  be  found  at  http://diana.gl. nps.navy.miFSimkit/doe/. 


For  generating  random  numbers: 

RandomVariate 

RandomV  ariateF  actory 

For  ealeulating  statistics: 

SimpleStatsTally 

3,  New  Classes 

Following  is  a  summary  of  the  new  elasses  built  for  the  UPPS.  Java  eode  for  all 
of  these  elasses  is  ineluded  in  Appendix  B. 

a.  PointSD 

PointSD  objeets  represent  points  (or  veetors)  in  3-dimensional  space. 

b.  Entity 

Entity  objeets  represent  entities  on  the  battlefield.  This  elass  is  a  super 
class  of  the  Sensor  and  Target  classes,  so  that  instanee  variables  and  methods  common  to 
these  two  elasses  would  not  have  to  be  written  twice.  This  elass  contains  two  different 
instanee  methods  for  computing  whether  LOS  exists  between  two  entities 
(hasLineOlSightTo  and  hasLOSTo) 
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c.  Sensor 

Sensor  objects  represent  sensors  on  the  battlefield.  This  is  a  simple  class, 
but  it  can  be  modified  if  we  want  to  construct  more  “complex”  sensors. 


d.  Target 

Target  objects  represent  targets  on  the  battlefield.  Again,  this  is  a  simple 
class,  but  it  can  be  modified  if  we  want  to  construct  more  “complex”  targets. 


e.  Building 

Building  objects  represent  buildings  in  an  urban  template.  Each  building 
has  an  array  of  line  segments  (Lme2D  objects)  representing  its  walls  (as  seen  from  a  top 
view)  and  a  Polygon  representing  its  “footprint”  (the  shape  of  the  building  as  seen  from  a 
top  view).  These  two  instance  variables  are  redundant,  but  the  redundancy  makes  the 
code  of  the  UPPS  easier  to  develop  and  understand. 

f.  PLOS 

This  is  the  pure  execution  class  that  executes  the  simulation.  This  is  the 
class  that  a  user  will  modify  to  change  the  sensor  elevation,  target  elevation,  range  bin 
size,  and  other  attributes  of  the  UPPS. 

4,  LOS  Algorithms 

Following  is  a  more  detailed  description  of  the  two  LOS  algorithms  used  in  the 
UPPS.  Again,  the  Java  code  for  these  methods  can  be  found  in  the  Entity  class  in 
Appendix  B. 


a.  hasLineOfSightTo 

This  LOS  method  should  be  used  when  incorporating  underlying  terrain 
skin  into  LOS  calculations.  The  LOS  algorithm  in  this  method  essentially  “steps”  along 
the  line  from  sensor  to  target  and  checks  the  slope  at  each  step  (if  any  of  these 
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intermediate  slopes  is  greater  than  the  slope  from  sensor  to  target,  then  LOS  does  not 
exist).  The  “steps”  taken  by  this  algorithm  are  at  every  gridline  erossed. 


b.  hasLOSTo 

This  LOS  method  should  be  used  when  assuming  that  the  underlying 
terrain  skin  will  have  a  negligible  effect  on  LOS.  The  LOS  algorithm  in  this  method 
takes  the  same  approach  as  the  hasLineOlSightTo  method  (“stepping”  along  the  line  from 
sensor  to  target  and  checking  slopes).  However,  the  only  points  checked  by  this  method 
along  the  line  from  sensor  to  target  are  where  the  sensor-target  line  intersects  a  building 
wall.  This  method  runs  much  faster  than  the  hasLineOlSightTo  method. 
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APPENDIX  B.  JAVA  CODE  FOR  THE  UPPS 


A.  CLASS  POINT3D 

/* 

*  PointSD.java 

* 

*  Created  on  Oetober  18,  2003,  5:50  PM 

V 

publie  elass  PointSD  implements  Cloneable  { 

private  double  x; 
private  double  y; 
private  double  z; 

publie  Point3D()  { 
this(0.0,  0.0); 

} 

publie  Point3D(double  xCoord,  double  yCoord)  { 
this(xCoord,  yCoord,  0.0); 

} 

publie  Point3D(double  xCoord,  double  yCoord,  double  zCoord)  { 
setPoint(xCoord,  yCoord,  zCoord); 
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} 

public  Point3D(Point3D  point)  { 
this(point.getX(),  point.getYQ,  point.getZ()); 

} 

public  Point3D  setPoint(double  xCoord,  double  yCoord,  double  zCoord)  { 
setX(xCoord); 
setY(yCoord); 
setZ(zCoord); 
return  this; 

} 

publie  Point3D  setPoint(Point3D  point)  { 
return  setPoint(point.getX(),  point.getYQ,  point.getZQ); 

} 


publie  double  getXQ  { 
return  x; 

} 

publie  void  setX(double  newX)  { 
X  =  newX; 

} 
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public  double  getY()  { 
return  y; 

} 

publie  void  setY (double  newY)  { 
y  =  newY ; 

} 

publie  double  getZ()  { 
return  z; 

} 

publie  void  setZ(double  newZ)  { 
z  =  newZ; 

} 

publie  PointSD  inerementBy(double  deltaX,  double  deltaY,  double  deltaZ)  { 
X  +=  deltaX; 
y  +=  deltaY ; 
z  +=  deltaZ; 
return  this; 

} 
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public  PointSD  incrementBy(Point3D  delta)  { 
return  incrementBy(delta.getX(),  delta.getYQ,  delta.getZ()); 

} 

publie  PointSD  deerementBy(double  deltaX,  double  deltaY,  double  deltaZ)  { 

X  -=  deltaX; 
y  -=  deltaY ; 
z  -=  deltaZ; 
return  this; 

} 

publie  PointSD  decrementBy(Point3D  delta)  { 
return  decrementBy(delta.getX(),  delta.getYQ,  delta.getZQ); 

} 

publie  Point3D  sealarMultiply(double  alpha)  { 

X  *=  alpha; 
y  *=  alpha; 
z  *=  alpha; 
return  this; 

} 

publie  double  distanceFrom( double  xCoord,  double  yCoord,  double  zCoord)  { 
return  Math.sqrt((xCoord  -  x)*(xCoord  -  x)  +  (yCoord  -  y)*(yCoord  -  y) 
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+  (zCoord  -  z)*(zCoord  -  z)); 


} 

public  double  distanceFrom(Point3D  point)  { 
return  distanceFrom(point.getX(),  point.getYQ,  point.getZQ); 

} 

publie  double  XYDistanceFrom( double  xCoord,  double  yCoord)  { 
return  Math.sqrt((xCoord  -  x)*(xCoord  -  x)  +  (yCoord  -  y)*(yCoord  -  y)); 

} 

public  double  XYDistaneeFrom(Point3D  point)  { 
return  XYDistanceFrom(point.getX(),  point.getYQ); 

} 

publie  double  slopeTo(double  xCoord,  double  yCoord,  double  zCoord)  { 
return  (zCoord  -  z)/XYDistanoeFrom(xCoord,  yCoord); 

} 

public  double  slopeTo(Point3D  point)  { 
return  slopeTo(point.getX(),  point.getYQ,  point.getZQ); 

} 


publie  double  XYSlopeTo(double  xCoord,  double  yCoord)  { 
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return  (yCoord  -  y)/(xCoord  -  x); 


} 

public  double  XYSlopeTo(Point3D  point)  { 
return  XYSlopeTo(point.getX(),  point.getY()); 

} 

public  Object  clone()  { 

PointSD  answer; 
try  { 

answer  =  (Point3D)super.clone(); 

} 

catch(CloneNotSupportedException  e)  { 
throw  new  RuntimeException("This  class  does  not  implement  cloneable"); 

} 

return  answer; 

} 

public  String  toString()  { 
return  "Pomt3D:  ("  +  x  +  ",  "  +  y  +  +  z  +  ")"; 

} 


} 


74 


B,  CLASS  ENTITY 

/* 

*  Entity  .java 

* 

*  Created  on  Oetober  18,  2003,  3:03  AM 

import  java. awt.geom.*; 

publie  elass  Entity  { 

private  Point3D  loeation; 

private  static  double  getXlntersectPoint(Eine2D  a,  Eine2D  b)  { 
if  (a.getXlO  ==  a.getX2())  { 
return  a.getXlQ; 

} 

if(b.getXl()  ==b.getX2()){ 
return  b.getXlQ; 

} 

double  slope  A,  slopeB; 

slopeA  =  (a.getY2()  -  a.getYl())/(a.getX2()  -  a.getXlQ); 
slopeB  =  (b.getY2()  -  b.getYl())/(b.getX2()  -  b.getXlQ); 

return  (slopeA*a.getXl()  -  slopeB*b.getXl()  +  b.getYlQ  -  a.getYl())/(slopeA  - 
slopeB); 
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} 


private  static  double  getYIntersectPoint(Line2D  a,  Line2D  b)  { 
if  (a.getXlO  ==  a.getX2())  { 

return  ((b.getY2()  -  b.getYl())/(b.getX2()  -  b.getXl()))*(getXIntersectPoint(a,  b) 
b.getXl())  +  b.getYl(); 

} 

else  { 

return  ((a.getY2()  -  a.getYl())/(a.getX2()  -  a.getXl()))*(getXIntersectPoint(a,  b) 
a.getXl())  +  a.getYl(); 

} 

} 

public  Entity(Point3D  initialLocation)  { 
setLocation(initialLocation); 

} 

public  PointSD  getLocation()  { 
return  (Point3D)location.clone(); 

} 

public  void  setLocation(Point3D  newLocation)  { 
location  =  (Point3D)newLocation.clone(); 

} 
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public  boolean  hasLine01EightTo(Entity  target,  double[][]  elevation)  { 
double  XYSlopeToTarget  =  location.XYSlopeTo(target.getLoeation()); 
PointSD  intermediateLoeation  =  new  Point3D(loeation); 
double  targetX  =  target.getLocation().getX(); 
double  targetY  =  target.getLoeation().getY(); 
double  sensorX  =  location.  getX(); 
double  sensorY  =  location.getY(); 
double  nextXLine; 
double  nextYLine; 


//Sensor  Upper-Left,  Target  Lower-Right 
if  (targetX  >  sensorX  &&  targetY  <  sensorY)  { 
nextXLine  =  Math.ceil(sensorX); 
nextYLine  =  Math.floor(sensorY); 
while  (nextXLine  <  targetX  ||  nextYLine  >  targetY)  { 


if  (XYSlopeToTarget  >=  intermediateLoeation.XYSlopeTo(nextXLine, 
nextYLine))  { 


intermediateLocation.inerementBy(target.getLoeation().decrementBy(intermediateLoeati 

on).scalarMultiply( 

(nextXLine  -  intermediateLoeation.getX())/(targetX 

intermediateLoeation.  getX()))); 

nextXLine  +=  1.0; 
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} 

else  { 


intermediateLocation.inerementBy(target.getLocation().deerementBy(intermediateLoeati 

on).scalarMultiply( 

(nextYLine  -  intermediateLoeation.getY())/(targetY 

intermediateLocation.getY  ()))); 

nextYLine  -=  1 .0; 

} 


if  (intermediateLoeation.getZO  < 


elevation[(int)Math.round(intermediateLoeation.getX())][(int)Math.round(intemiediateL 
ocation.getY())])  { 

return  false; 

} 


} 

return  true; 

} 


//Sensor  Lower-Left,  Target  Upper-Right 
else  if  (targetX  >  sensorX  &&  targetY  >  sensorY)  { 
nextXLine  =  Math.ceil(sensorX); 
nextYLine  =  Math.eeil(sensorY); 
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while  (nextXLine  <  targetX  ||  nextYLine  <  target Y)  { 


if  (XYSlopeToTarget  <  intermediateLoeation.XYSlopeTo(nextXLine, 
nextYLine))  { 


intermediateLocation.inerementBy(target.getLoeation().decrementBy(intermediateLoeati 

on).scalarMultiply( 

(nextXLine  -  intermediateLoeation.getX())/(targetX 

intermediateLocation.getXO))); 

nextXLine  +=  1.0; 

} 

else  { 

intermediateLoeation.inerementBy(target.getLoeation().deerementBy(intermediateLocati 

on).scalarMultiply( 

(nextYLine  -  intermediateLoeation.getY())/(targetY 

intermediateLocation.getY  ()))); 

nextYLine  +=  1.0; 

} 


if  (intermediateLocation.getZO  < 


elevation[(int)Math.round(intermediateLocation.getX())][(int)Math.round(intemiediateL 
oeation.getYO)])  { 

return  false; 
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} 


} 

return  true; 

} 

//Sensor  Right,  Target  Left 
else  { 

return  target.hasLine01EightTo(this,  elevation); 

} 

} 

public  boolean  hasLOSTo(Entity  target,  Building[]  building)  { 

PointSD  intermediateLocation  =  new  Point3D(); 

Line2D. Double  sensorTargetLine  =  new  Line2D.Double( 

location.  getX(),  location.getYQ,  target.getLocation().getX(), 

target .  getLoc  ation() .  getY  ()) ; 

double  intersectPoint; 

for(int  i  =  0;  i  <  building. length;  i++)  { 
for(intj  =  0;  j  <  building[i] . getWallQ. length;  j++)  { 
intermediateLocation.setPoint(location); 

if  (sensor! argetLine.intersectsLine(building[i].getWall()[j]))  { 
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if  (sensorTargetLine.getXlO  !=  sensorTargetLine.getX2())  { 

intersectPoint  =  getXIntersectPoint(sensorTargetLine, 

building[i].getWall()[j]); 


intermediateLocation.incrementBy(target.getLocation().decrementBy(intermediateLocati 

on).scalarMultiply( 

(intersectPoint  -  intermediateLocation.getX())/(target.getLocation().getX()  - 
intermediateLocation.getXO))); 

} 

else  { 

intersectPoint  =  getYIntersectPoint(sensorTargetLine, 

building[i].getWall()[j]); 


intermediateLocation.incrementBy(target.getLocation().decrementBy(intermediateLocati 

on).scalarMultiply( 

(intersectPoint  -  intermediateLocation.getY())/(target.getLocation().getY()  - 
intermediateLocation.getY  ()))); 

} 


if  (intermediateLocation.getZO  <  building [i].getHeight())  { 
return  false; 

} 

} 

} 

} 
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return  true; 


} 

publie  boolean  hasLine01EightTo(Entity  target,  Building[]  building)  { 
double  XYSlopeToTarget  =  loeation.XYSlopeTo(target.getLoeation()); 
PointSD  intermediateLoeation  =  new  Point3D(loeation); 
double  targetX  =  target.getLoeation().getX(); 
double  targetY  =  target.getLoeation().getY(); 
double  sensorX  =  loeation.getX(); 
double  sensorY  =  loeation.getY(); 
double  nextXLine; 
double  nextYLine; 
boolean  InBuilding; 
int  i; 

//Sensor  Upper-Left,  Target  Lower-Right 
if  (targetX  >  sensorX  &&  targetY  <  sensorY)  { 
nextXLine  =  Math.eeil(sensorX); 
nextYLine  =  Math.floor(sensorY); 
while  (nextXLine  <  targetX  ||  nextYLine  >  targetY)  { 

InBuilding  =  false; 
i=  1; 
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if  (XYSlopeToTarget  >=  intermediateLocation.XYSlopeTo(nextXLine, 
nextYLine))  { 

intermediateLocation.incrementBy(target.getLocation().decrementBy(intermediateLocati 

on).scalarMultiply( 

(nextXLine  -  intermediateLocation.getX())/(targetX 

intermediateLocation.getXO))); 

//System.out.println("Hit  Y  Line"); 

nextXLine  +=  1.0; 

} 

else  { 

//System.out.println("Hit  X  Line"); 

intermediateLoeation.incrementBy(target.getLoeation().decrementBy(intermediateLoeati 

on).scalarMultiply( 

(nextYLine  -  intermediateLoeation.getY())/(targetY 

intermediateLoeation.getY  ()))); 

//System.out.println(intermediateLocation); 

nextYLine  -=  1 .0; 

} 

while  (linBuilding  &&  i  <  building. length)  { 

//System.out.println("Checking  Building  "  +  i); 
//System.out.println(intermediateLoeation); 
if  (building[i].contains(intemiediateLoeation))  { 
inBuilding  =  true; 

//System.out.println("found"); 
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if  (intermediateLocation.getZ()  <  building[i].getHeight())  { 
return  false; 


} 

} 

i++; 

} 

} 

return  true; 

} 


//Sensor  Lower-Left,  Target  Upper-Right 
else  if  (targetX  >  sensorX  &&  targetY  >  sensorY)  { 
nextXLine  =  Math.ceil(sensorX); 
nextYLine  =  Math.ceil(sensorY); 
while  (nextXLine  <  targetX  ||  nextYLine  <  targetY)  { 

//System.out.println("Yo"); 
inBuilding  =  false; 
i=  1; 

if  (XYSlopeToTarget  <  intermediateLoeation.XYSlopeTo(nextXLine, 
nextYLine))  { 


intermediateLocation.inerementBy(target.getLoeation().decrementBy(intermediateLoeati 

on).scalarMultiply( 

(nextXLine  -  intermediateLoeation.getX())/(targetX 

intermediateLoeation.getXO))); 
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//System.out.println("Hit  Y  Line"); 
nextXLine  +=  1.0; 

} 

else  { 

//System.out.println("Hit  X  Line"); 

intermediateLoeation.inerementBy(target.getLoeation().deerementBy(intermediateLoeati 

on).sealarMultiply( 

(nextYLine  -  intermediateLoeation.getY())/(targetY 

intermediateLoeation.getY  ()))); 

//System.out.println(intermediateLoeation); 

nextYLine  +=  1.0; 

} 

while  (linBuilding  &&  i  <  building. length)  { 

//System.out.println("Cheeking  Building  "  +  i); 
//System.out.println(intermediateLoeation); 
if  (building[i].eontains(intermediateLoeation))  { 
inBuilding  =  true; 

//System.out.println("found"); 

if  (intermediateLocation.getZO  <  building[i].getHeight())  { 
return  false; 

} 

} 
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i++; 

} 

} 

return  true; 

} 

//Sensor  Right,  Target  Left 
else  { 

return  target.hasLine01SightTo(this,  building); 

} 

} 

public  String  toString()  { 
return  location.toString(); 

} 

} 
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C.  CLASS  SENSOR 

/* 

*  Sensor  .java 

* 

*  Created  on  Oetober  18,  2003,  2:40  AM 

publie  class  Sensor  extends  Entity  { 

private  double  maxRange; 

public  SensorQ  { 
this(new  Point3D()); 

} 

public  Sensor(Point3D  initialLocation)  { 
this(initialLocation,  Double.MAX_VALUE); 

} 

public  Sensor(Point3D  initialLocation,  double  initialMaxRange)  { 
super(initialLocation); 
setMaxRange(initialMaxRange); 

} 


public  double  getMaxRange()  { 
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return  maxRange; 


} 


public  void  setMaxRange(double  newMaxRange)  { 
maxRange  =  newMaxRange; 


} 


public  String  toString()  { 

return  super.toString()  +  "  Max  Range;  "  +  maxRange; 

} 


} 
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D,  CLASS  TARGET 

/* 

*  Target.]  ava 

* 

*  Created  on  Oetober  18,  2003,  2:58  AM 


import  java. awt.geom.*; 


public  class  Target  extends  Entity  { 


public  TargetO  { 
this(new  Point3D()); 


} 


public  Target(Point3D  initialLocation)  { 
super(initialLocation); 


} 


public  String  toString()  { 
return  super.toString(); 


} 


} 
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E,  CLASS  BUILDING 

/* 

*  Building  .java 

* 

*  Author:  Joe  Mlakar 

* 

*  Created  on  Oetober  18,  2003,  2:29  AM 

*/ 

import  j  ava.awt.  * ; 
import  java. awt.geom.*; 

publie  elass  Building  { 

private  Polygon  footprint; 
private  Line2D[]  wall; 
private  double  height; 

publie  Building(Polygon  initialFootprint,  Line2D[]  initialWall,  double  initialHeight)  { 
setFootprint(initialFootprint); 
setWall(initialWall); 
setHeight(initialHeight); 

} 


publie  Polygon  getFootprint()  { 
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return  footprint; 


} 

public  void  setFootprint(Polygon  newFootprint)  { 
footprint  =  newFootprint; 

} 

public  Line2D[]  getWall()  { 
return  (Line2D[])wall.clone(); 

} 

public  void  setWall(Line2D[]  newWall)  { 
wall  =  (Line2D[])newWall.clone(); 

} 

public  double  getHeight()  { 
return  height; 

} 

public  void  setHeight(double  newHeight)  { 
height  =  newHeight; 

} 

public  boolean  contains(double  x,  double  y,  double  z)  { 
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return  footprint.  contains(x,  y)  &&  z  <=  height; 

} 

public  boolean  contains(Point3D  point)  { 
return  contains(point.getX(),  point.  getY(),  point.  getZ()); 

} 

/* 

public  boolean  contains(double  x,  double  y)  { 

Double  buildingRightSide  =  new  Double(footprint.getX()  +  footprint.getWidth()); 
Double  buildingTopSide  =  new  Double(footprint.getY()  +  footprint.getHeight()); 
if  (footprint.  contains(x,  y)  || 

(buildingRightSide.equals(new  Double(x))  &&  x  >=  footprint.getY()  &&  x  < 
building! op S ide . double V alue())  1 1 

(buildingTopSide.equals(new  Double(y))&&  y  >=  footprint.getX()  &&  y  < 
buildingRightS ide .  double V alue()))  { 

return  true; 

} 

else  { 

return  false; 

} 

} 

*/ 

public  void  writeWalls()  { 
for  (int  i  =  0;  i  <  wall. length;  i++)  { 
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System. out. println("("  +  wall[i].getXl()  +  +  wall[i].getYl()  +  ")  to  ( 

+  wall[i].getX2()  +  +  wall[i].getY2()  + 


public  String  toString()  { 

return  "Building;  "  +  footprint.toString()  +  height; 

} 

} 
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F.  CLASS  PLOS 

/* 

*  PLOS. java 

* 

*  Created  on  Oetober  18,  2003,  3:24  AM 

import  java.util.*; 
import  java. io.*; 
import  j  ava.awt.  * ; 
import  java. awt.geom.*; 
import  simkit.*; 
import  simkit.  stat.*; 
import  simkit.util.*; 
import  simkit.random.*; 

publie  elass  PLOS  { 

publie  statie  void  main(String[]  args)  { 

//  deelare  variables 

String  inputstring; 

FileReader  inputFile; 

BufferedReader  inputUnit; 
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StringTokenizer  tokenizer; 


int  numberOfBuildings,  numberOfComers,  range; 
Building[]  building; 

Line2D[]  wall; 

int[]  xPoints,  yPoints; 

double  areaXLength,  areaYLength,  height; 

SimpleStatsTally  heightData  =  new  SimpleStatsTallyO; 

boolean  inBuilding; 

int  i; 

if  (args. length  ==  0)  { 

System.out.println("\nUsage;  java  PLOS  <lilename>"); 
return; 

} 


//  read  in  the  data 


try  { 

inputFile  =  new  FileReader(args[0]); 

inputUnit  =  new  BufferedReader(inputFile); 

inputstring  =  inputUnit.readLine(); 

tokenizer  =  new  StringTokenizer(inputString,"  "); 

areaXLength  =  Integer.parseInt(tokenizer.nextToken()); 
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areaYLength  =  Integer.parseInt(tokenizer.nextToken()); 
numberOfBuildings  =  Integer.parseInt(tokenizer.nextToken()); 

building  =  new  Building[numberOfBuildings]; 
i  =  0; 

while  ((inputstring  =  inputUnit.readLine())  !=  null)  { 
tokenizer  =  new  StringTokenizer(inputString,"  "); 

//  System,  out  .println(i) ; 

numberOfComers  =  Integer  .parselnt(  tokenizer. nextToken()); 
wall  =  new  Line2D[numberOfCorners]; 
xPoints  =  new  int[numberOfComers]; 
yPoints  =  new  int[numberOfComers]; 

for(int  j  =  0;j<  numberOfCorners;  j++)  { 
xPoints[j]  =  Integer.parseInt(tokenizer.nextToken()); 
yPoints[j]  =  Integer.parseInt(tokenizer.nextToken()); 
ifG>0){ 

wallQ-l]  =  new  Line2D.Double(xPoints[j-l],  yPoints[j-l],  xPoinisQ], 

yPoints[j]); 

} 

} 

wall  [wall,  length  -  1]  =  new  Line2D.Double(xPoints[wall. length  -  1], 

yPoints [wall. length  -  1],  xPoints[0],  yPoints[0]); 

height  =  Double.parseDouble(tokenizer.nextToken()); 
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building[i]  =  new  Building(new  Polygon(xPoints,  yPoints,  numberOfComers), 
wall,  height); 

heightData.newObservation(height); 

i++; 

} 

inputUnit.closeO; 

}  eateh(FileNotFoundExeeption  e)  { 

System,  out. println(e); 
return; 

}  eatch(IOExeeption  e)  { 

System,  out. println(e); 
return; 

} 

//  print  out  some  statisties  on  the  building  heights 

/* 

System.out.printlnC'Max  Building  Height:  "  +  heightData.getMaxObs()); 
System.out.printlnC'Min  Building  Height:  "  +  heightData.getMinObsO); 
System.out.printlnC'Mean  Building  Height:  "  +  heightData.getMeanQ); 
System.out.printlnC Standard  Deviation:  "  +  heightData.getStandardDeviationQ); 
System.out.printlnO; 

*/ 
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//  run  the  simulation 


//for(int  a  =  1;  a  <=  5;  a++)  { 

Sensor  sensor  =  new  Sensor(); 

Target  target  =  new  Target(); 

RandomVariate  u  =  RandomVariateFaetory.getInstanee( 

"Uniform",  new  Object[]  {new  Double(O.O),  new  Double(areaXLength)}, 

CongruentialSeeds.  SEED[  1  ]); 

RandomVariate  v  =  RandomVariateEaetory.getInstance( 

"Uniform",  new  Object[]  {new  Double(O.O),  new  Double(areaYEength)}, 

CongruentialSeeds. SEED[5]); 

int  binSize; 
binSize  =  5; 


SimpleStatsTally[]  bin  =  new 

SimpleStatsTally[(int)(Math.ceil(Math.sqrt(areaXEength*areaXEength  + 

areaYEength*areaYEength)  /  binSize)  +  1)]; 


for(int  k  =  0;  k  <  bin.length;  k++)  { 
bin[k]  =  new  SimpleStatsTally(); 

} 
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for(int  r  =  0;  r  <  10000;  r++)  { 
do  { 

inBuilding  =  false; 

1  =  0; 

sensor. setLocation(new  Point3D(u.generate(),  v.generate(),  20.0)); 
while  (! inBuilding  &&  i  <  building. length)  { 
if  (building[i].eontains(sensor.getLoeation()))  { 
inBuilding  =  true; 

} 

i++; 

} 

}  while  (inBuilding); 

do  { 

inBuilding  =  false; 
i  =  0; 

target. setLoeation(new  Point3D(u.generate(),  v.generate(),  0.0)); 
while  (! inBuilding  &&  i  <  building. length)  { 
if  (building[i].contains(target.getLoeation()))  { 
inBuilding  =  true; 

} 

i++; 

} 

}  while  (inBuilding); 
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range 

(int)Math.floor(sensor.getLocation().XYDistanceFrom(target.getLocation()))  /  binSize; 

/* 

System.out.println(sensor.getLocation()); 
System.out.println(target.getLocation()); 
System.out.println(sensor.hasLOSTo(target,  building)); 
System.out.println(sensor.hasLine01EightTo(target,  building)); 

*/ 

if  (sensor.hasLOSTo(target,  building))  { 
bin[range]  .newObservation(  1.0); 

} 

else  { 

bin[range].newObservation(0.0); 

} 


} 


for(int  k  =  0;  k  <  bin.length;  k++)  { 

System.out.println(binSize*(k+l)  +  ",  "  +  bin[k].getMean()  +  ",  "  + 

bin[k]  .getCountQ); 

} 

//} 
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} 


} 
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APPENDIX  C.  CODE  FOR  GENERATING  PLOS  ESTIMATES 

WITH  COMBAT  XXI 


/* 

File:  Location.java 

*/ 

/*  Copyright  Notice  =========================================* 

*  This  file  contains  proprietary  information  of  US  ATRAC- WSMR  and  USMC- 
MCCDC 

*  Copying  or  reproduction  without  prior  written  approval  is  prohibited. 

*  Copyright  (c)  1999  -  2004  ============*/ 

//  PACKAGE 
package  cxxi.util.geom; 

//  IMPORTS 

import  cxxi.util.geom.*; 

import  cxxi.util.tools.Units; 

import  cxxi.environmentservices.*; 

import  simkit.*; 

import  simkit.  stat.*; 

import  simkit.random.*; 

import  cxxi. coremodel. communications.msg.Sharable; 

import  java. awt.geom.Point2D; 
import  java.util.*; 

import  net. onesaf  services. data. dm. obj ects. ecs .coordinate . * ; 

/* 

TODO  When  new  env  services  are  hooked  up  add  code  to  initialize  elevation  to 
use  the  new  terrain  services. 

There  should  be  a  static  method  that  does  this  initialization 
*  as  soon  as  the  env  services  have  been  initialized. 

*/ 

/**  This  class  provide  a  way  of  specifying  locations  in  the  battle  space.  The 
representation 

*  used  is  based  on  the  geocentric  coordinate  system.  For  this  reason  x,  y  and  z 
cannot  be 

*  interpreted  to  mean  map  offsets  and  elevation.  Methods  are  provided  to  get  this 

type 

*  of  information  based  on  a  reference  ellipsoid. 
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=1= 


=1= 

*  History:  This  class  is  based  on  the  LoeationXYZ  elass  developed  by  Michael 
Shattuek  in 

*  Aug  1999.  Some  of  the  methods  used  here  are  lifted  from  that  class. 

* 

public  class  Location  implements  Cloneable,  Sharable 

{ 

/* 

=1= 

*  Static  attribute  for  the  class 

* 

*  Determine  if  the  validation  of  the  value  in  a  locatio  is  done  -  validation 

*  makes  sure  that  the  value  of  a  location  is  set  before  use.  If  this  flag  is 

*  false,  new  loeations  will  have  default  values  of  0.0  otherwise  default  values 

*  will  be  Double.NaN.  This  attribute  ean  be  used  by  other  elasses  in  the 

*  geom  paekage. 

*/ 

statie  final  boolean  validationOK  =  false; 

/**  flag  to  control  if  object  pooling  should  be  used  -  this  should  only 

*  be  used  during  development  of  this  meehanism  -  once  it  is  has  been  fully 

*  tested  the  pooling  should  be  left  on 

*/ 

private  static  boolean  ObjectPoolingDisabled  =  true; 

/**  The  structure  to  hold  the  pool  of  loeations  to  allow  for  the  recyeling  of 

*  loeation  objects.  Care  should  be  taken  when  recycling  locations  since  the 

*  information  in  the  object  is  lost.  Recycling  should  be  mainly  used  for  temp 

*  loeations  that  are  not  passed  to  other  parts  of  the  code. 

*/ 

private  statie  Veetor  loeationPool  =  new  Vector(); 

/**  This  is  a  handle  to  the  environment  services  that  are  being  used. 

*/ 

private  static  cxxi.environmentservices.ModTerrainService  mts  =  null; 

/**  This  attribute  holds  the  grid  zone  to  use  when  covering  to  Lat  Long  -  this 
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*  is  here  only  until  the  internal  conversion  to  GCC  is  done  -  at  that  time 

*  this  will  no  longer  be  needed. 

* 

*  !!!!!!!  Note  !!!!!!  for  now  it  is  assumed  that  the  entire  playbox  is  in  a 

*  single  grid  zone.  If  this  assumtion  is  violated  Locations  will  not  be 

correct!!!! 

*/ 

private  static  byte  gridZone  =  -100; 

//  attribute  to  allow  having  dummy  locations  outside  a  valid  play  zone 
private  static  double  dummyLong  =  Double.NaN; 

*  Default  Constructor 

*  All  coordinates  =  0.0. 

public 

LocationO 

{ 

superO; 

if  (validationOK) 

{ 

this.setX(Double.NaN); 

this.setY(Double.NaN); 

this.setZ(Double.NaN); 

} 

else 

{ 

this.setX(O.O); 

this.setY(O.O); 

this.setZ(O.O); 

} 


} 

/**  Return  a  location  set  to  the  latitude  and  longitude  passed  in.  The  elevation 

*  is  clamped  to  the  surface  of  the  terrain  skin. 

* 

*  @param  aLatitude  the  latitude  to  use 

*  @param  aLongitude  the  longitude  to  use 

*  @return  a  location  object  set  to  the  values  passed  in 
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public  static  Location  getInstanceInLatLon(  double  aLatitude,  double 
aLongitude) 

{ 

Loeation  temp  =  getALoeationQ; 
temp.setLatitudeAndLongitude(aLatitude,  aLongitude); 

return  temp; 

} 

/**  Return  a  loeation  set  to  the  latitude  and  longitude  passed  in.  The  elevation 

*  is  set  to  the  value  passed  in. 

* 

*  @param  aLatitude  the  latitude  to  use 

*  @param  aLongitude  the  longitude  to  use 

*  @param  elevation  the  elevation  above  mean  sea  level 

*  @return  a  loeation  object  set  to  the  values  passed  in 

*/ 

public  static  Location  getInstanceInLatLon(  double  aLatitude,  double 
aLongitude,  double  elevation) 

{ 

Loeation  temp  =  getALoeationQ; 

temp.setLatitudeAndLongitude(aLatitude,  aLongitude,  elevation); 
return  temp; 

} 

/**  Return  a  loeation  initialized  to  the  values  passed  in.  The  loeation  returned 

may 

*  either  be  new  or  taken  from  the  pool. 

*/ 

public  static  Location  getInstance(double  xValue,  double  y Value,  double 

z  Value) 

{ 

Loeation  temp  =  getALoeationQ; 
temp .  setX(x  V  alue) ; 
temp .  setY  (y  V  alue) ; 
temp .  setZ(z  V  alue) ; 

return  temp; 

} 

/**  Return  a  loeation  initialized  to  the  value  passed  in.  The  loeation  returned 

may 

*  either  be  new  or  taken  from  the  pool. 

V 
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public  static  Location  getInstance(Location  location) 

{ 

Location  temp  =  getALocationQ; 
temp.setLocation(location); 
return  temp; 

} 


it 

used 


/**  This  method  returns  a  "new"  loeation  -  this  may  either  be  newly  ereated  or 

*  ean  eome  from  the  objeet  pool.  If  there  are  objeets  in  the  pool,  these  are 

*  otherwise  a  new  objeet  is  ereated. 

*/ 

private  statie  Loeation  getALooation() 

{ 

if  (loeationPool.isEmptyO) 
return  new  Loeation(); 
else 
{ 

Loeation  temp  =  (Loeation)loeationPool.remove(O); 
temp.isInPool  =  false; 


return  temp; 

} 

} 

/**  return  a  loeation  that  is  in  the  eurrent  gridzone  but  outside  of  any 
reasonable 

*  playbox. 

*! 

publie  statie  Loeation  getDummyLooation() 

{ 

return  getInstaneeInLatLon(-85.0,  dummyLong,  0.0); 

} 


objeets 

this 

are 


/**  This  method  returns  this  instanee  of  Loeation  to  the  pool  of  Loeation 

*  that  ean  be  reused.  This  method  should  be  used  only  when  it  is  eertain  that 

*  loeation  is  not  used  by  any  other  objeet.  The  loeation  values  of  this  objeet 

*  erased.  After  this  method  is  ealled,  the  referenee  to  this  objeet  should  be  set 

*  to  null  or  overwritten.  For  Example: 

*  <br> 

*  <CODE> 

*  aEoeation.returnToPoolO; 
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*  alocation  =  null; 

*  </CODE> 

*/ 

public  void  returnToPool() 

{ 

if  (ObjectPoolingDisabled)  return; 

if  (this.isInPool) 

{ 

System.err.println("/n****WARNING:  Location  Pool"  + 

"  -  trying  to  return  a  location  that  is  already  in  the  pool  "  + 
Integer.toHexString(this.hashCode())  +  "/n/n"); 

} 

else 

{ 

this.setX(Double.NaN); 

this.setY(Double.NaN); 

this.setZ(Double.NaN); 

this. locked  =  false; 

this.isInPool  =  true; 

this.latLonIsSet  =  false; 

this.isClampedToTerrainSkin  =  false; 

locationPool.add(this); 

} 

} 


*  Determin  if  this  location  has  valid  values. 

*! 

public  boolean  isIllDefined() 

{ 

if  (validationOK) 

return  (Double. isNaN(myX)  ||  Double. isNaN(myY) 

Double. isNaN(myZ)); 
else 

return  false; 


*/ 

public  double  getLatitude() 

{ 

if  (llatLonIsSet) 

{ 
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if  (mts  ==  null) 

System.err.println("\n  ***  ERROR  cannot  get  at  terrain  serviees  in 

Location\n"); 

else 

{ 

geotransform.eoords.Utm_Coord_3d  utm3d  =  new 

geotransform.eoords.Utm_Coord_3d(); 

utm3d.x  =  myX; 
utm3d.y  =  myY; 
utm3d.z  =  myZ; 

utm3d.liemisphere_north  =  true; 
utm3d.zone  =  gridZone; 

geotransform.eoords.Gdc_Coord_3d  gdc3d  =  new 

geotransform,  eoords.  Gde_Coord_3  d(); 

geotransfonn.transforms.Utm_To_Gdo_Converter.Convert(utm3d, 

gdc3d); 

this. latitude  =  gdc3d.latitude; 
this,  longitude  =  gdc3d.longitude; 
this. elevation  =  gdc3d.  elevation; 
latLonIsSet  =  true; 

} 

} 

return  this. latitude; 

} 

*/ 

publie  double  getLongitude() 

{ 

getLatitudeO; 
return  this. longitude; 

} 

/**  This  returns  the  distance  above  sea  level  in  meters  -  this  should 

*  be  the  same  value  that  is  returned  by  getAltitudeMSL.  The  reason  for  two 

*  methods  is  that  refering  to  elevation  make  more  senee  when  dealing  with 

*  things  on  the  ground  and  using  altitude  is  more  meaningfull  for  aireraft. 

*/ 

publie  double  getElevation() 

{ 

return  myZ; 

} 

/*=!= 

*/ 
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public  double  getNorthingO 

{ 

return  my  Y ; 

} 

*/ 

public  double  getEastingO 

{ 

return  myX; 

} 

*/ 

publie  int  getGridZone() 

{ 

return  myGridZone; 

} 

public  boolean  isNorthernHemisphere() 

{ 

return  northernHemisphere; 

} 

/**  return  if  this  loeation  has  been  clamped  to  the  surfaee  of  the  earth 

*/ 

public  boolean  isClampedToTerrainSkinO 

{ 

return  IsClampedToTerrainSkin; 

} 


*/ 

publie  double  getAltitudeMSL() 

{ 

return  getElevation(); 

} 

/**  Modify  this  loeation  so  that  its  projection  onto  the  surfaee  of  the  Earth 

*  does  not  change  while  its  distance  above  mean  sea  level  is  the  distance 

passed  in 

*  @param  altitude  the  new  altitude  value  in  meters 


no 


*/ 

public  void  setAltitudeMSL(double  altitude) 

{ 

//******  Implementation  NOTE!!!!! 

//  latLonIsSet  does  not  need  to  be  changed  beeause  this  transformation  does 
not 

//  affeet  the  lat  and  ion  values 
if(this.isIllDefined()) 

throw  new  IllegalStateExeeption(" Attempted  to  use  ill-defined  Eoeation"); 
//  Cannot  modify  a  looked  objeot 
if(this.isEooked())  { 

throw  new  IllegalStateExoeption("Attempted  modify  looked  Eoeation 

objeot."); 

} 

myZ  =  altitude; 
elevation  =  myZ; 
isClampedToTerrainSkin  =  false; 

} 

/**  This  method  sets  the  "elevation"  of  this  point  to  be  height  meters  above 

*  the  terrain  skin.  This  method  is  intended  to  be  used  when  looations  need  to 

*  be  speoified  that  are  above  the  terrain  skin  by  a  small  amount  suoh  as  sensor 

*  looations  or  positions  inside  of  multistoried  buildings. 

* 

*  @param  height  the  translated  point  should  be  above  the  surfaoe  (meters) 

*/ 

public  void  setHeightAboveTerrainSkin( double  height) 

{ 

//******  Implementation  NOTE!!!!! 

//  latEonIsSet  does  not  need  to  be  ohanged  beeause  this  transformation  does 
not 

//  affeet  the  lat  and  Ion  values 
olampT  oT  errainSkin(); 

myZ  +=  height;  //  this  needs  to  be  redone  when  the  GCC  based  looation  is 

integrated. 

elevation  =  myZ; 
isClampedToTerrainSkin  =  false; 

} 

*  Clamp  the  elevation  value  of  this  looation  to  the  elevation  at  the  surfaoe 

*  of  the  earth.  This  method  goes  to  the  ourrent  environment  servioes  and  gets 
the 

*  elevation  of  the  olosest  point  on  the  surfaoe  of  the  earth  to  this  point  and 

*  set  the  elevation  to  it. 


Ill 


=1= 


*/ 

public  void  clampToTerrainSkin() 

{ 

//******  Implementation  NOTE!!!!! 

//  latLonIsSet  does  not  need  to  be  ehanged  beeause  this  transformation  does 
not 

//  affeet  the  lat  and  ion  values 
if(this.isIllDefined()) 

throw  new  IllegalStateExeeption(" Attempted  to  use  ill-defined  Eoeation"); 

//  Cannot  modify  a  looked  objeot 
if(this.isEooked())  { 

throw  new  IllegalStateExoeption("Attempted  modify  looked  Eoeation 

objeot."); 

} 

//  make  sure  we  have  initialized  the  environmet  servioes 
if  (mts  ==  null) 

{ 

mts  = 

oxxi.environmentservioes.EnvironmentServioes.ModTerrainServioeO; 
if  (mts  ==  null) 

{ 

throw  new  IllegalStateExoeption("  ****  Error  in  Eoeation:  "  + 

"Tried  to  use  olampToTerrainSkin  before  terrain  servioes  were 

initialized\n"  + 

"  This  Eoeation  elevation  not  set  to  the  terrain  skin  value\n\n"); 

} 

} 

oxxi.environmentservioes.Elevation  looalElevation  = 
mts.getElevation(this); 
myZ  =  looalElevation.getTerrainHeightO; 
elevation  =  myZ; 
isClampedToTerrainSkin  =  true; 

} 


*  Determine  if  two  XYZ  ooordinates  are  equal. 

*  @param  xl  x-ooordinate  of  first  position. 

*  @param  yl  y-ooordinate  of  first  position. 

*  @param  zl  z-ooordinate  of  first  position. 

*  @param  x2  x-ooordinate  of  first  position. 

*  @param  y2  y-ooordinate  of  first  position. 
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*  @param  z2  z-coordinate  of  first  position. 

*  @retum  true  if  coordinates  are  equal 

public  static  boolean 

CoordinatesEqual3D(double  xl, 
double  yl, 
double  zl, 
double  x2, 
double  y2, 
double  z2) 

{ 

boolean  equal  =  false; 

if  (StrictMath.abs(xl  -  x2)  <=  Double. MrN_VALUE  && 
StrictMath.abs(yl  -  y2)  <=  Double.MIN_VAEElE  && 
StrictMath.abs(zl  -  z2)  <=  Double.MIN  VALElE) 

{ 

equal  =  true; 

} 

return  equal; 

} 


*  Get  the  x  coordinate. 

*  <p> 

*  @retum  the  x-coordinate  of  this  location. 

double 

getX() 

{ 

return  myX; 

} 


*  Get  the  y  coordinate. 

*  <p> 

*  @retum  the  y-coordinate  of  this  location. 

double 

getY() 

{ 

return  my  Y ; 

} 
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*  Get  the  z  coordinate. 

*  <p> 

*  @retum  the  z-coordinate  of  this  location. 

double 

getZO 

{ 

return  myZ; 

} 

*  Returns  the  distance  from  this  Location  to  a  specified  Location. 

*  This  is  the  same  as  the  Euclidean  3D  distance. 

*  <p> 

*  Distance  is  the  degree  or  amount  of  separation  between  two  points, 

*  lines,  surfaces,  or  objects;  or  an  extent  of  an  area  or  an  advance 

*  along  a  route  measured  linearly;  or  an  extent  of  space  measured  other 

*  than  linearly;  or  an  extent  of  advance  from  a  beginning. 

*  <p> 

*  @param  toLoc  The  other  location. 

*  @return  instance  of  Distance  that  represents  the  distance. 

public  Distance 
distanceTo(Location  toLoc) 

{ 


double  dist; 
if(this.isIllDefined()) 

throw  new  IllegalStateException(" Attempted  to  use  ill-defined  Eocation"); 
if(toEoc .  isIllDefinedO) 

throw  new  IllegalStateException("Attempted  to  use  ill-defined  Eocation  as 
an  input  argument"); 

double  distSq; 

Eocation  that  =  (Eocation)  toEoc; 

double  deltaX  =  this.getX()  -  that.getX(); 
double  deltaY  =  this.getY()  -  that.getY(); 
double  deltaZ  =  this.getZ()  -  that.getZ(); 

dist  =  StrictMath.sqrt((deltaX  *  deltaX)  + 

(deltaY  *  deltaY)  + 

(deltaZ  *  deltaZ)); 

return  Distance. getlnstance(dist); 

} 
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public  double 

groundDistanceTo(Location  toLoc) 

{ 


if(this.isIllDefined()) 

throw  new  IllegalStateException(" Attempted  to  use  ill-defined  Location"); 
if(toLoc .  isIllDefinedO) 

throw  new  IllegalStateExeeption("Attempted  to  use  ill-defined  Location  as 
an  input  argument"); 

Loeation  that  =  (Loeation)  toLoe; 

double  deltaX  =  this.getXQ  -  that.getX(); 
double  deltaY  =  this.getYQ  -  that.getY(); 


return  StrietMath.sqrt((deltaX  *  deltaX)  + 
(deltaY  *  deltaY)); 


} 

*  Returns  the  square  of  the  distance  from  this  Loeation  to  another. 

*  This  is  the  same  as  the  square  of  the  Euclidean  3D  distance. 

*  <p> 

*  Distance  is  the  degree  or  amount  of  separation  between  two  points, 

*  lines,  surfaees,  or  objects;  or  an  extent  of  an  area  or  an  advance 

*  along  a  route  measured  linearly;  or  an  extent  of  space  measured  other 

*  than  linearly;  or  an  extent  of  advance  from  a  beginning. 

*  <p> 

*  @param  toLocation  The  other  loeation. 

*  @return  instanee  of  Distanee  that  represents  the  distance. 

public  Distance 

distanceToSqrd(Location  toLoc) 

{ 

if(this.isIllDefined()) 

throw  new  IllegalStateExeeption(" Attempted  to  use  ill-defined  Location"); 
if(toLoc .  isIllDefinedO) 

throw  new  IllegalStateException("Attempted  to  use  ill-defined  Location  as 
an  input  argument"); 

double  distSq; 

Location  that  =  (Location)  toLoc; 
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double  deltaX  =  this.getX()  -  that.getX(); 
double  deltaY  =  this.getYQ  -  that.getY(); 
double  deltaZ  =  this.getZQ  -  that.getZQ; 

distSq  =  (deltaX  *  deltaX)  + 

(deltaY  *  deltaY)  + 

(deltaZ  *  deltaZ); 

return  Distanee.getlnstanee(distSq); 

} 


*  Calculate  the  direction  from  this  location  to  another. 

*  <p> 

*  Direction  is  the  line  or  course  on  which  something  is  moving  or  is 

*  aimed  to  move  or  along  which  something  is  pointing  or  facing. 

*  <p> 

*  @param  toLoc  The  other  location. 

*  @return  The  direction  from  this  location  to  toLoc. 

public  Direction 
directionTo(Location  toLoc) 

{ 

if(this.isIllDefined()) 

throw  new  IllegalStateException(" Attempted  to  use  ill-defined  Location"); 
if(toLoc .  isIllDefinedO) 

throw  new  IllegalStateException("Attempted  to  use  ill-defined  Eocation  as 
an  input  argument"); 

double  distSq; 
double  deltaX; 
double  deltaY ; 
double  deltaZ; 

Eocation  that  =  (Location)  toLoc; 

deltaX  =  that.getX()  -  this.getX(); 
deltaY  =  that.getY()  -  this.getY(); 
deltaZ  =  that.getZO  -  this.getZ(); 

Direction  direct  =  new  Direction(deltaX,  deltaY,  deltaZ); 
return  direct; 

} 
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*  Calculate  a  new  location  based  on  the  direction  and  distance  from 

*  this  location. 

*  <p> 

*  @param  direction  The  direction  to  the  new  loeation. 

*  @param  distanee  The  distanee  to  the  new  loeation. 

*  @return  The  new  loeation. 

public  Location 

getTranslatedLocation(Direction  direction, 

Distance  distance) 

{ 

if(this.isIllDefined()) 

throw  new  IllegalStateExeeption(" Attempted  to  use  ill-defined  Location"); 
if(direction.  isIllDefinedO) 

throw  new  IllegalStateExeeption(" Attempted  to  use  ill-defined  Direction 
as  an  argument"); 

if(distance.isIllDefined()) 

throw  new  IllegalStateException(" Attempted  to  use  ill-defined  Distanee  as 

an  argument"); 

double  distSq; 
double[]  dirCosines  = 

direction.getDireetionCosines(); 

double  xOffset  = 

distance. getMetersO  *  dirCosines[0]; 
double  yOffset  = 

distanee. getMetersO  *  dirCosines[l]; 
double  zOffset  = 

distanee. getMetersO  *  dirCosines[2]; 

return  getInstance(this.getXO  +  xOffset, 
this.getYO  +  yOffset, 
this.getZO  +  zOffset); 

} 


*  Caleulate  a  new  location  based  on  the  direction  and  distance  from 

*  this  location. 

*  <p> 

*  @param  offset  from  this  loeation  to  the  new  loeation. 

*  @return  The  new  loeation. 
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public  Location 

getTranslatedLocation(Offset  anOffset) 

{ 

return  this.getTranslatedLocation( 

anOffset.getDirectionQ,  anOffset.getDistanceQ); 

} 

*  Calculate  a  new  loeation  offest  from  this  loeation  using  a  veloeity  and 

*  time.  This  assumes  that  the  veloeity  is  eonstant  for  the  full  time  period. 

*  @param  aVeloeity  the  veloeity  to  use 

*  @param  sTime  the  time  in  seeonds  that  the  movement  is  to  take  place 

* 

*  @return  the  new  loeation 

*/ 

publie  Loeation 

getTranslatedLooation(Velooity  aVeloeity, 
double  aTime) 

{ 


if(this.isIllDefined()) 

throw  new  IllegalStateExeeption(" Attempted  to  use  ill-defined  Loeation"); 
if(aVelooity.isIllDefmed()) 

throw  new  IllegalStateExeeption(" Attempted  to  use  ill-defined  Veloeity  as 

an  argument"); 

if(aTime  <  0.0) 

throw  new  IllegalStateExeeption("Attempted  to  use  negative  time  as  an 

argument"); 


Direetion  aDir  =  aVeloeity. getDirectionQ; 

Distanee  aDist  =  Distanee.getInstanee(aVeloeity.getSpeed()  *  aTime); 
return  getTranslatedLoeation(aDir,  aDist); 

} 


*  Assign  a  new  loeation  to  this  instanee. 

*  <p> 

*  @param  loeation  The  new  loeation. 
public  void 

setEocation(Eocation  location) 

{ 

//  Cannot  modify  a  locked  objeet 
if(this.isEoeked()) 

{ 
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throw  new  IllegalStateException("Attempted  modify  locked  Location 

object."); 

} 

if  (location  !=  null) 

{ 

this.myX  =  location.getX(); 
this.myY  =  location.getY(); 
this.myZ  =  location.getZ(); 
this.latLonIsSet  =  location.latLonIsSet; 
this. elevation  =  location.elevation; 
this. latitude  =  location.latitude; 
this. longitude  =  location,  longitude; 

this.isClampedToTerrainSkin  =  location.  isClampedToTerrainSkin; 

} 

} 


*  Set  a  new  value  for  the  x-coordinate. 

*  <p> 

*  @param  x Value  :  the  x-coordinate  to  set. 
void 

setX(  double  x  Value) 

{ 

//  Cannot  modify  a  locked  object 
if(this.isLocked())  { 

throw  new  IllegalStateException("Attempted  modify  locked  Location 

object."); 

} 

myX  =  xValue; 
latLonIsSet  =  false; 
isClampedToTerrainSkin  =  false; 

} 

*  Set  a  new  value  for  the  y-coordinate. 

*  <p> 

*  @param  y Value  :  the  y-coordinate  to  set. 
void 

setY(double  yValue) 

{ 

//  Cannot  modify  a  locked  object 
if(this.isLocked())  { 
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throw  new  IllegalStateException("Attempted  modify  locked  Location 

object."); 

} 

myY  =  y  Value; 
latLonIsSet  =  false; 
isClampedToTerrainSkin  =  false; 

} 

/**  Set  a  new  value  for  the  z-coordinate. 

*  <p> 

*  @param  Z Value  the  z  value 

V 

void 

setZ(double  Z Value) 

{ 

//  Cannot  modify  a  locked  object 
if(this.isLocked())  { 

throw  new  IllegalStateException("Attempted  modify  locked  Location 

object."); 

} 

myZ  =  Z  Value; 
latLonIsSet  =  false; 
isClampedToTerrainSkin  =  false; 

} 


*  Set  this  location  to  the  lat  Ion  passed  in  and  clamp  the  elevation  to 

*  the  terrain  skin. 

*/ 

private  void  setLatitudeAndLongitude(double  aLatitude,  double  aLongitude) 

{ 

setLatitudeAndLongitude(  aLatitude,  aLongitude,  0.0); 
this.clampToTerrainSkinO; 

} 


*  Set  this  location  to  the  lat  Ion  passed  in  and  set  the  elevation  to 

*  the  value  pased  in. 

*/ 

private  void  setLatitudeAndLongitude(double  aLatitude,  double  aLongitude, 
double  anElevation) 

{ 

geotransform.coords.Gdc_Coord_3d  gdc3d  = 
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new  geotransform.coords.Gdc_Coord_3d(aLatitude,  aLongitude, 

elevation); 


geotransform.eoords.Utm_Coord_3d  utm3d  =  new 

geotransfomi.coords.Utm_Coord_3d(); 

geotransform.transfomis.Gdc_To_Utm_Converter.Convert(gde3d,  utm3d); 

this.setX(utm3d.x); 

this.setY(utm3d.y); 

this.setZ(anElevation); 

this.myGridZone  =  utm3d.zone; 

this.northernHemisphere  =  utm3d.hemisphere_north; 

if  (gridZone  <  -60) 

gridZone  =  utm3d.zone; 
else 

if  (gridZone  !=  utm3d.zone) 

{ 

System. err.println("\n****  ERROR  with  loeations  -  playbox  appears  to 
span  grid  zones!!!  " 

+  gridZone  +  "  and  "  +  utm3d.zone); 

} 

if  (Double. isNaN(dummyEong)) 
dummyEong  =  aEongitude; 

latitude  =  aEatitude; 
longitude  =  aEongitude; 
elevation  =  anElevation; 
latEonIsSet  =  true; 

} 


*  Cheek  if  this  loeation  is  the  same  as  another. 

*  @param  object  should  be  an  instance  of  Eocation. 

*  @retum  true  if  the  passed  in  object  is  a  location 

*  with  the  same  coordinates. 

public  boolean 
equals(Object  object) 

{ 

boolean  locationsEqual  =  false; 

if  (object  instanceof  Eocation) 

{ 
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Location  thatLocation  = 

(Location)  ((Location)  object); 

if  (CoordinatesEqual3D(getX(), 
getYO, 
getZ(), 

thatLocation.  getX(), 
thatLocation.  getY  (), 
thatLocation.  getZ()) 

) 

{ 

locationsEqual  =  true; 

} 

} 

return  loeationsEqual; 

} 


/*  HashCode  is  implemented  because  equals  is  overwritten  in  this  class. 

*  This  implementation  based  on  "Effective  Java"  —Jason  Bloeh,  Sun  2001,  Ch 
3,  pp  38-39 

*  The  hashcode  uses  Eoeation  hashcode  and  the  route  nodetype  hashcode. 

* 

*  @return  int  hashCode  that  is  unique  to  this  object  and  differs  in  the  near 

fields. 

*/ 

public  int  hashCode() 

{ 

if(myHashCode  ==  0) 

{ 

long  xCode  =  Double. doubleToEongBits(myX); 
long  yCode  =  Double. doubleToEongBits(myY); 
long  zCode  =  Double. doubleToEongBits(myZ); 
int  result  =17; 

result  =  37*result  +  (int)(xCode^(xCode»>32)); 
result  =  37*result  +  (int)(yCode^(yCode»>32)); 
result  =  37*result  +  (int)(zCode^(zCode»>32)); 
myHashCode  =  result; 

} 

return  myHashCode; 

} 

void 

elearO 
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{ 


//  Cannot  modify  a  locked  object 
if(this.isLocked())  { 

throw  new  IllegalStateException("Attempted  modify  locked  Loeation 

object."); 

} 

myX  =  myY  =  myZ  =  Double.NaN; 
latLonIsSet  =  false; 
isClampedToTerrainSkin  =  false; 

} 


*  return  a  string  representation  of  this  loeation. 

*  Overrides  toString  method  from  Object. 

public  String 
toStringO 
{ 

java.text.DecimalFormat  df  =  new  java.text.DecimalFormat("0.00"); 
StringBuffer  stringBuf  =  new  StringBuffer("Foeation("); 
stringBuf  append(df  format(this.getX())  +  ",  "); 

StringBuf  append(df  format( this. getY())  +  ",  "); 

StringBuf  append(dfformat(this.getZ())  +  ")"); 
return  new  String(stringBuf); 

} 


SHAREABFE  METHODS 

===============================================  =N/ 


*  This  method  is  required  to  implement  Sharable.  It  loeks  the  object 

*  preventing  further  modifieation  of  it's  data. 

* 

*  @see  exxi. coremodel. oommunioations.Sharable#look 

*/ 

public  void  lock()  { 
locked  =  true; 

} 
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*  This  method  is  required  to  implement  Sharable.  It  returns 

*  the  loek  state  of  the  objeet. 

* 

*  @see  exxi.eoremodel.communieations.Sharable#isLoeked 

*  @return  loek  state  of  the  objeet 

*/ 

publie  boolean  isLoeked()  { 
return  loeked; 

} 


*  This  method  is  required  to  implement  Sharable.  Returns 

*  a  deep  copy  of  the  object  with  locked  set  to  false. 

* 

*  @see  cxxi. coremodel. communications. Sharable#getMutableCopy 

*  @return  a  deep  copy  of  the  locked  object 

*/ 

public  Object  getMutableCopyO  { 

Location  newLocation  =  null; 
try  { 

newLocation  =  (Location)this.clone(); 
newLocation.locked  =  false; 

} 

catch(Exception  e)  { 

//  ignore  as  this  should  never  occur 

} 

return  newLocation; 

} 


CLONEABLE  METHODS 

===============================================  =N/ 


public  Object  clone()  throws  CloneNotSupportedException  { 
Eocation  newEocation  =  (Eocation)super.clone(); 

return  newEocation; 

} 


/* 

================================================  * 

*  Static  support  methods 

*  Implementation  Note:  perhaps  these  methods  should  be  in  some 
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*  kind  of  support  class.  If  there  are  only  a  few  this  is 

*  probably  a  good  place  for  them.  But  if  the  number  grows 

*  they  should  probably  me  in  their  own  class. 

* 

===============================================  =N/ 


*  Determine  if  two  XY  eoordinates  are  equal. 

*  @param  xl  x-coordinate  of  first  position. 

*  @param  yl  y-coordinate  of  first  position. 

*  @param  x2  x-eoordinate  of  first  position. 

*  @param  y2  y-coordinate  of  first  position. 

*  @retum  true  if  coordinates  are  equal 

public  static  boolean 
CoordinatesEqual2D(double  xl, 
double  yl, 
double  x2, 
double  y2) 

{ 

boolean  equal  =  false; 

if  (StrictMath.abs(xl  -  x2)  <=  Double. MIN_VALUE  && 
StrietMath.abs(yl  -  y2)  <=  Double. MIN_VALE1E) 

{ 

equal  =  true; 

} 

return  equal; 

} 


/**  Compute  the  mathematical  center  of  mass  of  the  loeations  passed  in.  No 

*  assumptions  are  made  about  the  meaning  of  x,  y  and  z  (i.e.  z  is  NOT 

assumed 

*  to  be  elevation). 

* 

*  @param  loeations  the  list  of  locations  whose  center  of  mass  should  be 

*  found  -  all  elements  of  the  list  should  be  of  Eocation  type. 

*  @return  a  point  that  is  the  mathematieal  center  of  the  points.  A  null  is 

*  returned  if  the  list  passed  in  is  empty. 

*/ 

public  static  Eocation  calculateCenterOf!VIass(Eist  locations) 

{ 

if  (locations. size()  <  1) 
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return  null; 

//  establish  a  eenter  point 
double  xetr  =  0; 
double  yetr  =  0; 
double  zctr  =  0; 

Location  tempLoc  =  null; 

//  iterate  through  the  list  summing  the  coordinates 
for(mt  i=0;i<locations.size();i++) 

{ 

tempLoc  =  (Location)locations.get(i); 

xetr  =  xetr  +  tempLoc. getX(); 
yetr  =  yetr  +  tempLoc. getY(); 
zctr  =  zctr  +  tempLoc. getZ(); 

}//  end  i  for 

//  divide  by  the  number  of  points  to  get  arithmatic  center 
xetr  =  xctr/((double)locations.size()); 
yetr  =  yctr/((double)locations.size()); 
zctr  =  zctr/((double)locations.size()); 

Location  centerOfMass  =  Location. getlnstance(xctr,  yetr,  zctr); 
return  centerOfMass; 

}//  end  calculateCenterOfMassMethod  method 

//  Static  block  to  initialize  the  converstions  needed  for  this  class 
static 
{ 

//  ah  conversion  intitializations  should  go  here 

geotransform.transforms.Gdc_To_Utm_Converter.Init(); 

geotransform.transforms.Utm_To_Gdc_Converter.Init(); 

} 

================================================  * 

ATTRIBUTES 

* 

================================================  */ 


//  for  the  sharable  interface 
private  boolean  locked  =  false; 
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protected  double  myX  =  0.0; 
protected  double  myY  =  0.0; 
protected  double  myZ  =  0.0; 

private  byte  myGridZone  =  -1; 

private  boolean  northemHemisphere  =  true; 

//  these  attributes  are  used  to  cut  down  on  the  transformations  needed 

//  when  getting  the  value  of  this  location  in  terms  of  other  coordinate  systems 

private  double  latitude  =  Double.NaN; 

private  double  longitude  =  Double.NaN; 

private  double  elevation  =  Double.NaN; 

//  this  flag  indicates  if  the  lat  Ion  values  have  been  set  to  match  the  current 
//  X,  y,  z.  Whenever  x,  y,  or  z  are  changed  this  flag  should  be  set  to  false. 

When 

//  a  call  is  made  to  get  a  lat  or  Ion  value  the  conversion  is  done  and  the  result  is 
//  saved  and  this  flage  is  set  to  true  so  that  if  the  values  are  needed  again  the 
//  convrsion  does  not  need  to  be  done  again, 
private  boolean  latLonIsSet  =  false; 

private  int  myHashCode; 

/**  flag  to  indicate  if  this  location  is  already  in  the  pool 

*/ 

private  boolean  isInPool  =  false; 

//  Flag  to  indicate  if  this  location  has  been  forced  to  be  on  the  terrain  skin 
private  boolean  isClampedToTerrainSkin  =  false; 

*  class  test. 

*/ 

public  static  void  main(String[]  args) 

{ 

Location  temp,  temp2; 


//  initiialize  the  terrain  for  testing 

StringBuffer  errors  =  new  StringBuffer(); 

cxxi.environmentservices.EnvironmentServices.Initialize( 

"C:\\Program 

FilesWCXXIWcxxibasedataWenvirWCommercialRibbonSmoothCropped.ele", 

"dummy",  errors); 

System.out.println(  errors); 

mts  =  cxxi.environmentservices.EnvironmentServices.ModTerrainService(); 
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if  (mts  !=  null) 

{ 

//  set  up  box  to  sample 

/* 

*  SWLatitude  =  27.0476678 
SWLongitude  =  57.330884 
NELatitude  =  27.0544301 
NELongitude  =  57.338477 

*/ 

double  llEat  =  27.0476678; 
double  llEong  =  57.330884; 

Eoeation  upperRight  =  getInstanceInLatEon(27.0544301,  57.338477); 
Eoeation  lowerEeft  =  getInstaneeInLatEon(llLat,  llEong); 
double  latRange  =  upperRight.getEatitude()  -  lowerEeft.getEatitude(); 
double  longRange  =  upperRight.getEongitude() 
lowerEeft.getEongitudeQ; 

SimpleStatsTally[]  bin  =  new  SimpleStatsTally[250]; 

int  binSize; 
binSize  =  5; 


int  range; 

for(int  i  =  0;i<  bin.  length;  i++)  { 
bin[i]  =  new  SimpleStatsTally(); 

} 

Eoeation  sensor  =  new  Eoeation(); 

Eoeation  target  =  new  Eoeation(); 

RandomVariate  u  =  RandomVariateEaetory.getInstanee("Elniform",  new 
Objeet[]  {new  Double(O.O),  new  Double(l.O)},  CongruentialSeeds.SEED[5]); 

RandomVariate  v  =  RandomVariateEaetory.getInstanee("Elniform",  new 
Objeet[]  {new  Double(O.O),  new  Double(l.O)},  CongruentialSeeds.SEED[7]); 


/*  System.out.println("ElR,  EE,  Viewer:  "+ 

upperRight.getEatitudeQ  +  ",  "  +  upperRight. getEongitude()  +  ",  "  + 
lowerEeft.getEatitudeO  +  ", "  +  lowerEeft.getEongitude()  +  ", "  + 
viewer.getEatitudeO  +  ", "  +  viewer.getEongitude()); 
System.out.println("Viewer  Altitude:  "+viewer.getAltitudeMSE()); 

*/ 

for  (int  i  =  0;  i  <  1000000;  i++) 

{ 
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sensor  =  getInstanceInLatLon(llLat  +  (latRange  *  v.generate()  ),  llLong 
+  (longRange  *  u.generateQ  )); 

sensor.setZ(780.0); 

do  { 

target  =  getInstaneeInLatLon(llLat  +  (latRange  *  v.generate()  ), 
llLong  +  (longRange  *  u.generate()  )); 

}  while  (target. getAltitudeMSLO  >  280.0); 

//System.out.print("Sensor  Altitude  -  "  +  sensor. getZ()); 
//System.out.print("Target  Altitude  -  "+  target.getAltitudeMSL()); 
//System.out.println("Distanee  -  "  +  sensor.groundDistanceTo(target)); 
/*if  (mts.isLine01Eight(sensor,  target)) 

System.out.println("  TRUE  -  "+  target. getLatitude()  +  ",  "  + 
target.getLongitudeO  +",  "+ 

lowerLeft.getLatitudeO  +  +  lowerLeft.getLongitude()); 

else 

System.out.println("  FALSE  -  "+  upperRight.getLatitude()  +  ",  "  + 
upperRight.getLongitudeO 

+  ", "  +  target. getLatitudeO  +  ", "  +  target.getLongitudeO); 

*/ 

range  =  (int)Math.floor(sensor.groundDistanceTo(target))  /  binSize; 

if  (mts.isLine01Sight(sensor,  target))  { 
bin[range]  .newObservation(  1 .0); 

} 

else  { 

bin[range].newObservation(0.0); 

} 

} 

for(int  i  =  0;i<  bin.  length;  i++)  { 

System.out.println(binSize*(i+l)  +  ",  "  +  bin[i].getMean()  +  ",  "  + 
bin[i].getCount()); 

} 

} 

else 

{ 

System. err .println(" could  not  init  terrain  file"); 

} 


} 


}  //  Location  class. 
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